Under Construction

This is a page that analyzes the self serve control loops and its possible designs. Some of it might not really fit this feature but might spill over to others.

How to handle (at least) two levels of Policy parameter value filling?

The existing code seems to divide policy definitions to two distinct parts, the type and the instance, as is common for many modeling systems. However, it would seem the "natural" flow of service design and instantiation needs more phases and these would need to be encoded.

Example service with multiple control loops

The following diagrams shows a hypothetical simplified EPC (4G core network) with only some scaling control loops included. This is still only a very small sample of control loops that would be needed for it in reality if all of them would be implemented at ONAP level. Still, this sample tries to be complex enough compared to current demo cases to showcase some issues with the simplest extensions of current approach. 

PGW and SGW can be considered to be VNFs as the basic case but the control loop design and management should be the same if they are implemented using some other supported VIM, like Kubernetes. Also PNFs should work similarly but some actions like scale out are not available. Only scaling control loops are included for simplicity. Each VNF can scale along two dimensions (or aspects): user plane and control plane and the choice between these is encoded in the operational policy action towards SO. All control loops are based on TCA for simplicity. The example is based on separate instance of TCA for each control loop, but deployment type (kubernetes pod, VM, CDAP program, Spark job, etc.) of TCA functionality per control loop does not really matter from this point of view as long as logically separate TCA functionality gets deployed on run time.

Common for all Options

The clearest part of the feature is to enable generation of the TOSCA policy type definitions and related data types per service based on the used policy types. For the example case this means that there is a TCA policy type included in the service TOSCA possibly along with the operational policy type. There are some options for the nature of these policy types and these are shown in more detail in the sections below. 

This has three main loosely coupled parts that would most probably usually be done by different people with different expertise at different times in real use:

1. Onboarding of a DCAE service component with its configuration policy type according to MicroServices Onboarding in ONAP based on the TOSCA definitions created from the DCAE Component Spec. This has a number of considerations and options of its own, but they will be explored in a separate page. For the purposes of this page, this is expected to be completed and the DCAE service component to be available for service design along with its policy type. 

2. Onboarding of a new operational policy type. An operational policy type is tied to a particular Drools controller or its analogue in other PDP types. This is expected to be out of scope for this feature. However, depending on the service design options the current Drools operational policy might need to be represented in SDC and included to any service CSARs where it is used.

3. Designing a service with rich set of control loops with DCAE micro services, their policies and operational policies. These get encoded to a service CSAR, preferably TOSCA encoded, to be distributed to run time where it is instantiated and the instances further managed. This page is mostly about how to handle this part and what should the resulting CSAR look like.

Example Dublin service policies.yml and datatypes.yml for comparison attached. Each option includes an example of the corresponding TOSCA models for comparison.

If the blueprints are encoded as before to CSAR, the EPC CSAR will have the file structure as shown below. The options add various files to this:

Other examples are shown without current SDC file structure for compactness. This does not affect the model properties, only the division to files

Option 1: All Parameter Value Setting on CLAMP

This is the most straightforward extension of the current functionality and probably what has been originally intended in the scope of self serve control loops.

And example of generated TOSCA

Comparison with Dublin

In Dublin all supported policy types and their included data types are included in every service TOSCA. With this option only the policies and data types actually used in the service are generated. For the example case of only TCA based policies, the TCA policy and data types are the same as in Dublin, but other policies and related data types are excluded from the service TOSCA.

Evaluation

Pros

1. Relatively simple localized implementation

2. This part of new implementation is mostly needed by any of the larger options, so this looks like a good first step regardless of bigger ambitions.

3. Even with larger options this case of not defining any values in design time and leaving everything from run time needs to be still supported as a special case. It is not very easy to imagine what kind of realistic functionality would logically have every one of its policy parameters as instance specific, but there does not seem to be any good reasons for restricting this.

Cons

1. The design of control loop structure is almost totally left for instances and CLAMP.

2. The CSAR does not encode any knowledge about what kinds of events does it apply to

3. The CSAR does not encode anything about actions or operational policy in general

As most of the policy parameters remain the same for each service instance and the number of control loops for realistic services becomes large, this forces a lot of repetition in CLAMP without actually enforcing any value level regularity from service design. Especially for services with frequent instantiation this will essentially force keeping this level of modeling in some external system, most probably a script using CLAMP APIs. Thus part of the service model essentially starts to live outside ONAP.

Option 2: Derived Policy Types

TOSCA type system is essentially based on prototypes that can be overridden in derived types. This is in contrast to many programming languages where a base type or interface defines a contract that is not supposed to be broken by derived types. 

This mechanism can be used for nicely setting an arbitrary subset of policy parameters by creating deriving a new policy type for each instance or role of a policy in a service definition. Let's call this PolicyRole to avoid confusion. Note that PolicyRole is analogous to ResourceInstance in SDC that defines that a service contains an instance of a resource with certain parameters and relations specific to the containing service. In some sense this defines a role in the context of a particular service type. It is distinct from the concept of an instance as something in the run time and if a service type gets instantiated multiple times, so does the PolicyRole and ResourceInstance, so each can have multiple real instances.

In the example each of the six control loops has a separate PolicyRole derived from the generic TCA policy. Each sets custom default values for the policy parameters that the service designer thinks will either be valid for all instances of the service or at least provides a reasonable default for a particular role in the context of the particular service. Service designer can even force a certain value by using TOSCA constraints if CLAMP is updated to honor the constraints.

And example of generated TOSCA below. The example includes derived types for one PolicyRole, PGWUSerPlaneScaling. Full TOSCA for this EPC service would have similar derived type for each of its 6 PolicyRoles. The includes many detailed considerations about how to handle some situations at TOSCA level how to enable or restrict further choice in CLAMP. 

Evaluation

Pros

1. Brings the concept of PolicyRole to design time. Something resembling this concept seems to be needed for more complex services with more complex set of control loops.

2. Enable service design phase to customize arbitrary policy parameters for a particular role and service.

3. Fits nicely to TOSCA syntax and semantics 

Cons

1. The number of policy types grows quite large. This might cause some presentation and performance issues. 

Option 3: Inclusion to Topology Templates

Option 4: Separate Artifact for Clamp with Default Policy Values

It is also possible to pass the information about the design time values for PolicyRoles outside of the main TOSCA model, similarly as the blueprint is passed now. In this case every PolicyRole would get a file in the CSAR 

The main TOSCA model stays identical to Option 1.

Evaluation

Pros

1. Simple separation of concerns. 

Cons

1. Bigger part of the service model is left outside of (main) TOSCA, making overall model handling more complex. 

2. Standard TOSCA tooling will not work with these