diff options
| -rw-r--r-- | docs/sections/architecture.rst | 41 | ||||
| -rw-r--r-- | docs/sections/example.rst | 87 | ||||
| -rw-r--r-- | docs/sections/homingspecification.rst | 47 |
3 files changed, 156 insertions, 19 deletions
diff --git a/docs/sections/architecture.rst b/docs/sections/architecture.rst index 88507fc..cfbd535 100644 --- a/docs/sections/architecture.rst +++ b/docs/sections/architecture.rst @@ -6,32 +6,35 @@ Architecture Introduction ------------------ -OOF-HAS is an policy-driven placement optimizing service (or homing service) that allows ONAP to deploy services -automatically across multiple sites and multiple clouds. It enables placement based on a wide variety of policy -constraints including capacity, location, platform capabilities, and other service specific constraints. - -HAS is a distributed resource broker that enables automated policy-driven optimized placement of services on a -global heterogeneous platform using ONAP. Given a set of service components (based on SO decomposition flows) -and requirements for placing these components (driven by policies), HAS finds optimal resources (cloud regions -or existing service instances) to home these service components such that it meets all the service requirements. -HAS is architected as an extensible homing service that can accommodate a growing set of homing objectives, policy -constraints, data sources and placement algorithms. It is also service-agnostic by design and can easily onboard -new services with minimal effort. Therefore, HAS naturally extends to a general policy-driven optimizing placement -platform for wider range of services, e.g., DCAE micro-services, ECOMP control loops, server capacity, etc. -Finally, HAS provides an traceable mechanism for what-if analysis which is critical for ease of understanding a +OOF-HAS is an policy-driven placement optimizing service (or homing service) that allows ONAP to deploy services +automatically across multiple sites and multiple clouds. It enables placement based on a wide variety of policy +constraints including capacity, location, platform capabilities, and other service specific constraints. In +Frankfurt release, it is also used for the E2E Network Slicing use case to select an appropriate existing Network +Slice Instance (NSI) / Network Slice Sub-net Instances (NSSIs), and/or provide the Slice Profile for creating a +new NSSI which shall be part of a new NSI. + +HAS is a distributed resource broker that enables automated policy-driven optimized placement of services on a +global heterogeneous platform using ONAP. Given a set of service components (based on SO decomposition flows) +and requirements for placing these components (driven by policies), HAS finds optimal resources (cloud regions +or existing service instances) to home these service components such that it meets all the service requirements. +HAS is architected as an extensible homing service that can accommodate a growing set of homing objectives, policy +constraints, data sources and placement algorithms. It is also service-agnostic by design and can easily onboard +new services with minimal effort. Therefore, HAS naturally extends to a general policy-driven optimizing placement +platform for wider range of services, e.g., DCAE micro-services, ECOMP control loops, server capacity, etc. +Finally, HAS provides an traceable mechanism for what-if analysis which is critical for ease of understanding a homing recommendation and resolving infeasibility scenarios. HAS in Service Instantiation workflows -------------------------------------------- -Below is an illustration of HAS interactions with other ONAP components to enable Policy driven homing. The homing +Below is an illustration of HAS interactions with other ONAP components to enable Policy driven homing. The homing policy constraints have been expanded (and categorized) to highlight the range of constraints that could be provided -to HAS for determining the homing solution. The figure also shows how HAS uses a plugin-based approach to allow an -extensible set of constraints and data models. +to HAS for determining the homing solution. The figure also shows how HAS uses a plugin-based approach to allow an +extensible set of constraints and data models. .. image:: ./diagrams/HAS_PolicyDrivenHoming.png -More information on how homing constraints are specified can be found at OOF-HAS Homing Specification Guide, and a -sample homing template has been drawn up for residential vCPE Homing Use Case. +More information on how homing constraints are specified can be found at OOF-HAS Homing Specification Guide, and a +sample homing template has been drawn up for residential vCPE Homing Use Case. HAS Architecture (R2) ---------------------- @@ -49,6 +52,8 @@ Residential vCPE: https://wiki.onap.org/display/DW/vCPE+Homing+Use+Case 5G RAN: https://wiki.onap.org/display/DW/Homing+5G+RAN+VNFs +E2E Network Slicing: https://wiki.onap.org/display/DW/E2E+Network+Slicing+Use+Case+in+R6+Frankfurt + A sample heuristic greedy algorithm of HAS (using a vCPE as example) ------------------------------------------------------------------------ diff --git a/docs/sections/example.rst b/docs/sections/example.rst index 0339236..c2254e0 100644 --- a/docs/sections/example.rst +++ b/docs/sections/example.rst @@ -226,8 +226,93 @@ This is similar to the first example except that it has an additional distance constraint which specifies that the distance of each vnf from the customer location must be less than 500km. +Example 3 +--------- + +.. code:: json + + { + "files": {}, + "limit": 10, + "name": "urllc_sample", + "num_solution": "10", + "template": { + "constraints": { + "URLLC_core_Threshold": { + "demands": [ + "URLLC_core" + ], + "properties": { + "evaluate": [ + { + "attribute": "latency", + "operator": "lte", + "threshold": 30, + "unit": "ms" + } + ] + }, + "type": "threshold" + }, + "URLLC_ran_Threshold": { + "demands": [ + "URLLC_ran" + ], + "properties": { + "evaluate": [ + { + "attribute": "latency", + "operator": "lte", + "threshold": 30, + "unit": "ms" + } + ] + }, + "type": "threshold" + } + }, + "demands": { + "URLLC_core": [ + { + "filtering_attributes": { + "model-invariant-id": "21d57d4b-52ad-4d3c-a798-248b5bb9124a", + "model-version-id": "bfba363e-e39c-4bd9-a9d5-1371c28f4d22", + "orchestration-status": "active", + "service-role": "nssi" + }, + "inventory_provider": "aai", + "inventory_type": "nssi", + "region": "RegionOne", + "unique": "true" + } + ], + "URLLC_ran": [ + { + "filtering_attributes": { + "model-invariant-id": "aa2d56ea-773d-11ea-bc55-0242ac130003", + "model-version-id": "d6296806-773d-11ea-bc55-0242ac130003", + "orchestration-status": "active", + "service-role": "nssi" + }, + "inventory_provider": "aai", + "inventory_type": "nssi", + "region": "RegionOne", + "unique": "true" + } + ] + }, + "homing_template_version": "2018-02-01" + }, + "timeout": 1200 + } + +This template is for the selecting the NSSI instances for Network +Slicing use case. The demand here is the Slice subnets and the threshold +constraint specifies that the latency of the the subnets must be less +than a particular threshold. + + Contact ------- Shankar Narayanan shankarpnsn@gmail.com -a diff --git a/docs/sections/homingspecification.rst b/docs/sections/homingspecification.rst index 8684ffa..855e0ba 100644 --- a/docs/sections/homingspecification.rst +++ b/docs/sections/homingspecification.rst @@ -191,6 +191,7 @@ a *placemark*). +-----------------------------------+----------------------------------+ **Note:** + - A geocoder could be used to convert placemarks to a latitude/longitude @@ -923,6 +924,10 @@ Constraint Types | | specific | | | location/address. | +-------------------------------------------+--------------------------+ +| ``threshold`` | Constraint that checks if| +| | an attribute is within | +| | the threshold. | ++-------------------------------------------+--------------------------+ *Note: Constraint names marked “Deferred” **will not** be supported in the current release of HAS.* @@ -1918,6 +1923,48 @@ environment. template: http://repository/my/stack_template environment: http://repository/my/stack_environment +Threshold +~~~~~~~~~ + +Constrain each demand by an attribute which is within a certain +threshold. + +**Schema** + ++---------------+--------------------------------------------------------+ +| Property | Value | ++===============+========================================================+ +| ``evaluate`` | List of attributes and its threshold | ++---------------+--------------------------------------------------------+ + ++-------------------------+------------------------------------------+ +| Property for evaluation | Value | ++=========================+==========================================+ +| ``attribute`` | Attribute of a candidate | ++-------------------------+------------------------------------------+ +| ``threshold`` | Threshold Value | ++-------------------------+------------------------------------------+ +| ``operator`` | Condition to check. Supported Values are | +| | ``gte``, ``lte``, ``lt``, ``gt``, ``eq`` | ++-------------------------+------------------------------------------+ +| ``unit`` (optional) | Attribute's unit of measurement | ++-------------------------+------------------------------------------+ + +.. code:: yaml + + urllc_threshold: + type: threshold + demands: ['URLLC'] + properties: + evaluate: + - attribute: latency + operator: lte + threshold: 50 + unit: ms + - attribute: reliability + operator: gte + threshold: 99.99 + **Note:** - The status of the constraint support is of Frankfurt release. |