...
For example, assume we have policies for the SON (Self Organizing Network) and BBS (Boradband Service) domains. For SON, we have XACML, Drools, and APEX policies, and for BBS we have XACML and Drools policies. The table below shows the resultingPDPGroup, PDPSubGroup, and PDP allocations:
| PDP Group | PDP Subgroup | Kubernetes Deployment | Kubernetes Deployment Strategy | PDPs in Pods |
|---|---|---|---|---|
| SON | SON-XACML | SON-XACML-Dep | Always 2, be geo redundant | 2 PDP-X |
SON-Drools | SON-Drools-Dep | At Least 4, scale up on 70% load, scale down on 40% load, be geo-redundant | >= 4 PDP-D | |
| SON-APEX | SON-APEX-Dep | At Least 3, scale up on 70% load, scale down on 40% load, be geo-redundant | >= 3 PDP-A | |
| BBS | BBS-XACML | BBS-XACML-Dep | Always 2 | 2 PDP-X |
| BBS-Drools | BBS-Drools-Dep | At Least 2, scale up on 80% load, scale down on 50% load | >=2 PDP-D |
2.1 Policy Framework Object Model
...
2.2.2.1 Policy Design in the ONAP Policy Framework
Policy Design creation in the ONAP framework PolicyDevelopment follows the general sequence shown in the sequence diagram below. An API_USER is any component that wants to specialize create a policy template into from a concrete policy template. The ONAP Policy Framework PolicyDevelopment supplies a REST interface that exposes the API and also provides a command line tool and general purpose client that wraps the API.
An API_User
| Drawio | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
A PolicyDevAPIUser first gets a reference to and the metadata for the Policy Template for the policy they want to work on from PolicyDesign PolicyDevelopment. PolicyDesign PolicyDevelopment reads the metadata for the template from the database and reads the policy template artifact from Nexus. The API_User then asks for a reference and the metadata for the policy. PolicyDesign PolicyDevelopment looks up the policy in the database. If the policy already exists, PolicyDesign PolicyDevelopment reads the artifact from Nexus and returns the reference of the existing policy to the APIUser the PolicyDevAPIUser with the metadata for the existing policy. If the policy does not exist, PolicyDesign PolicyDevelopment creates and new reference and metadata and returns that to the API_User.
The API_User The PolicyDevAPIUser may now proceed with a policy specification session, where the models, rules, tasks, and flow for the policy are specified on the policy template. Many actual API calls may occur during the session to specify information on the policy.
Once the API_User the PolicyDevAPIUser is happy that the policy is completely and correctly specified, it requests PolicyDesign requests PolicyDevelopment to generate create the policy. PolicyDesign generates PolicyDevelopment creates the policy, stores the generated created policy artifact in Nexus and stores its metadata of the policy in the database.
...
Policy execution is carried out using the current life cycle mode of operation of the PDP. While the actual implementation of the mode may vary somewhat between PDPs of different types, the principles below hold true for all PDP types:
| Lifecycle Mode | Behaviour |
|---|---|
| PASSIVE MODE | Policy execution is always rejected irrespective of PDP type. |
| ACTIVE MODE | Policy execution is executed in the live environment by the PDP. |
| SAFE MODE | Policy execution proceeds, but changes to domain state or context are not carried out. The PDP returns an indication that it is running in SAFE mode together with the action it would have performed if it was operating in ACTIVE mode. The PDP type and the policy templates it is running must support SAFE mode operation. |
| TEST MODE | Policy execution proceeds and changes to domain and state are carried out in a test or sandbox environment. The PDP returns an indication it is running in TEST mode together with the action it has performed on the test environment. The PDP type and the policy templates it is running must support TEST mode operation. |
2.3.5 Policy Lifecycle Management
...