Example 1
---------
-.. code:: yaml
+.. code:: json
- name: yyy-yyy-yyyy
- files: {}
- timeout: 600
- limit: 1
- template:
- homing_template_version: '2018-02-01'
- parameters:
- service_name: ''
- service_id: d61b2543-5914-4b8f-8e81-81e38575b8ec
- customer_lat: 32.89748
- customer_long: -97.040443
- locations:
- customer_loc:
- latitude:
- get_param: customer_lat
- longitude:
- get_param: customer_long
- demands:
- vGMuxInfra:
- - inventory_provider: aai
- inventory_type: service
- service_type: vGMuxInfra-xx
- attributes:
- customer-id: ''
- orchestration-status: ''
- model-invariant-id: b3dc6465-942c-42af-8464-2bf85b6e504b
- model-version-id: ba3b8981-9a9c-4945-92aa-486234ec321f
- service-type: vGMuxInfra-xx
- equipment-role: ''
- global-customer-id: SDN-ETHERNET-INTERNET
- vG:
- - inventory_provider: aai
- inventory_type: cloud
- service_type: 71d563e8-e714-4393-8f99-cc480144a05e
- constraints:
- affinity_vCPE:
- type: zone
- demands:
- - vGMuxInfra
- - vG
- properties:
- category: complex
- qualifier: same
- optimization:
- minimize:
- sum:
- - product:
- - '1'
- - distance_between:
- - customer_loc
- - vGMuxInfra
- - product:
- - '1'
- - distance_between:
- - customer_loc
- - vG
+ {
+ "name": "yyy-yyy-yyyy",
+ "files": {},
+ "timeout": 600,
+ "limit": 1,
+ "num_solutions": 10,
+ "template": {
+ "homing_template_version": "2018-02-01",
+ "parameters": {
+ "service_name": "",
+ "service_id": "d61b2543-5914-4b8f-8e81-81e38575b8ec",
+ "customer_lat": 32.89748,
+ "customer_long": -97.040443
+ },
+ "locations": {
+ "customer_loc": {
+ "latitude": {
+ "get_param": "customer_lat"
+ },
+ "longitude": {
+ "get_param": "customer_long"
+ }
+ }
+ },
+ "demands": {
+ "vGMuxInfra": [
+ {
+ "inventory_provider": "aai",
+ "inventory_type": "service",
+ "service_type": "vGMuxInfra-xx",
+ "attributes": {
+ "customer-id": "",
+ "orchestration-status": "",
+ "model-invariant-id": "b3dc6465-942c-42af-8464-2bf85b6e504b",
+ "model-version-id": "ba3b8981-9a9c-4945-92aa-486234ec321f",
+ "service-type": "vGMuxInfra-xx",
+ "equipment-role": "",
+ "global-customer-id": "SDN-ETHERNET-INTERNET"
+ }
+ }
+ ],
+ "vG": [
+ {
+ "inventory_provider": "aai",
+ "inventory_type": "cloud",
+ "service_type": "71d563e8-e714-4393-8f99-cc480144a05e"
+ }
+ ]
+ },
+ "constraints": {
+ "affinity_vCPE": {
+ "type": "zone",
+ "demands": [
+ "vGMuxInfra",
+ "vG"
+ ],
+ "properties": {
+ "category": "complex",
+ "qualifier": "same"
+ }
+ }
+ },
+ "optimization": {
+ "minimize": {
+ "sum": [
+ {
+ "product": [
+ "1",
+ {
+ "distance_between": [
+ "customer_loc",
+ "vGMuxInfra"
+ ]
+ }
+ ]
+ },
+ {
+ "product": [
+ "1",
+ {
+ "distance_between": [
+ "customer_loc",
+ "vG"
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ }
+ }
+ }
-Example 1
+The example template is for the placement of vG and vGMuxInfra. It has
+an affinity constraint which specifies that both the vnfs must be in
+the same complex. The optimiation here is to minimize the sum of the
+distances of the vnfs from the customer location.
+
+Example 2
---------
-.. code:: yaml
+.. code:: json
+
+ {
+ "files": {},
+ "limit": 1,
+ "num_solutions": 10,
+ "name": "a2e3e0cc-3a97-44fc-8a08-1b86143fbdd3",
+ "template": {
+ "constraints": {
+ "affinity_vCPE": {
+ "demands": [
+ "vgMuxAR",
+ "vGW"
+ ],
+ "properties": {
+ "category": "complex",
+ "qualifier": "same"
+ },
+ "type": "zone"
+ },
+ "distance-vGMuxAR": {
+ "demands": [
+ "vgMuxAR"
+ ],
+ "properties": {
+ "distance": "< 500 km",
+ "location": "customer_loc"
+ },
+ "type": "distance_to_location"
+ },
+ "distance-vGW": {
+ "demands": [
+ "vGW"
+ ],
+ "properties": {
+ "distance": "< 1500 km",
+ "location": "customer_loc"
+ },
+ "type": "distance_to_location"
+ }
+ },
+ "demands": {
+ "vGW": [
+ {
+ "attributes": {
+ "model-invariant-id": "782c87a6-b712-47d1-9c5b-1ea2cd9a2dd5",
+ "model-version-id": "9877dbbe-8ada-40a2-8adb-f6f26f1ad9ab"
+ },
+ "inventory_provider": "aai",
+ "inventory_type": "cloud",
+ "service_type": "c3e0e82b-3367-48ce-ab00-27dc2e91a34a"
+ }
+ ],
+ "vgMuxAR": [
+ {
+ "attributes": {
+ "global-customer-id": "SDN-ETHERNET-INTERNET",
+ "model-invariant-id": "565d5b75-11b8-41be-9991-ee03a0049159",
+ "model-version-id": "61414c6c-6082-4e03-9824-bf53c3582b78"
+ },
+ "inventory_provider": "aai",
+ "inventory_type": "service",
+ "service_type": "46b29078-8442-4ea3-bea6-9199a7d514d4"
+ }
+ ]
+ },
+ "homing_template_version": "2017-10-10",
+ "locations": {
+ "customer_loc": {
+ "latitude": {
+ "get_param": "customer_lat"
+ },
+ "longitude": {
+ "get_param": "customer_long"
+ }
+ }
+ },
+ "optimization": {
+ "minimize": {
+ "sum": [
+ {
+ "product": [
+ "1",
+ {
+ "distance_between": [
+ "customer_loc",
+ "vgMuxAR"
+ ]
+ }
+ ]
+ },
+ {
+ "product": [
+ "1",
+ {
+ "distance_between": [
+ "customer_loc",
+ "vGW"
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ },
+ "parameters": {
+ "customer_lat": 32.89748,
+ "customer_long": 97.040443,
+ "service_id": "0dbb9d5f-27d9-429b-bc36-293e9fab7731",
+ "service_name": ""
+ }
+ },
+ "timeout": 600
+ }
+
+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.
- files: {}
- limit: 1
- name: a2e3e0cc-3a97-44fc-8a08-1b86143fbdd3
- template:
- constraints:
- affinity_vCPE:
- demands:
- - vgMuxAR
- - vGW
- properties:
- category: complex
- qualifier: same
- type: zone
- distance-vGMuxAR:
- demands:
- - vgMuxAR
- properties:
- distance: "< 500 km"
- location: customer_loc
- type: distance_to_location
- distance-vGW:
- demands:
- - vGW
- properties:
- distance: "< 1500 km"
- location: customer_loc
- type: distance_to_location
- demands:
- vGW:
- - attributes:
- model-invariant-id: 782c87a6-b712-47d1-9c5b-1ea2cd9a2dd5
- model-version-id: 9877dbbe-8ada-40a2-8adb-f6f26f1ad9ab
- inventory_provider: aai
- inventory_type: cloud
- service_type: c3e0e82b-3367-48ce-ab00-27dc2e91a34a
- vgMuxAR:
- - attributes:
- global-customer-id: SDN-ETHERNET-INTERNET
- model-invariant-id: 565d5b75-11b8-41be-9991-ee03a0049159
- model-version-id: 61414c6c-6082-4e03-9824-bf53c3582b78
- inventory_provider: aai
- inventory_type: service
- service_type: 46b29078-8442-4ea3-bea6-9199a7d514d4
- homing_template_version: '2017-10-10'
- locations:
- customer_loc:
- latitude:
- get_param: customer_lat
- longitude:
- get_param: customer_long
- optimization:
- minimize:
- sum:
- - product:
- - '1'
- - distance_between:
- - customer_loc
- - vgMuxAR
- - product:
- - '1'
- - distance_between:
- - customer_loc
- - vGW
- parameters:
- customer_lat: 32.89748
- customer_long: 97.040443
- service_id: 0dbb9d5f-27d9-429b-bc36-293e9fab7731
- service_name: ''
- timeout: 600
-
Contact
-------
Shankar Narayanan shankarpnsn@gmail.com
-a
\ No newline at end of file
+a
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. Copyright (C) 2017-2018 AT&T Intellectual Property. All rights reserved.
+.. Copyright (C) 2020 Wipro Limited. All rights reserved.
Homing Specification Guide
==========================
An address expressed in geographic region-agnostic terms (referred to as
a *placemark*).
-*Support for this schema is deferred.*
+*This is an example as of Frankfurt release. Support for this schema is
+ deferred to subsequent release.*
+-----------------------------------+----------------------------------+
| Key | Value |
| | information for the placemark. |
+-----------------------------------+----------------------------------+
-**Questions**
-
-- What geocoder can we use to convert placemarks to a
- latitude/longitude?
+**Note:**
+- A geocoder could be used to convert placemarks to a
+ latitude/longitude
Examples
~~~~~~~~
**Provider-agnostic Schema**
-+---------------------------------+------------------------------------+
-| Key | Value |
-+=================================+====================================+
-| ``inventory_provider`` | A HAS-supported inventory |
-| | provider. |
-+---------------------------------+------------------------------------+
-| ``inventory_type`` | The reserved word ``cloud`` (for |
-| | cloud regions) or the reserved |
-| | word ``service`` (for existing |
-| | service instances). Exactly one |
-| | inventory type may be specified. |
-+---------------------------------+------------------------------------+
-| ``attributes`` (Optional) | A list of key-value pairs, that is |
-| | used to select inventory |
-| | candidates that match *all* the |
-| | specified attributes. The key |
-| | should be a uniquely identifiable |
-| | attribute at the inventory |
-| | provider. |
-+---------------------------------+------------------------------------+
-| ``service_type`` (Optional) | If ``inventory_type`` is |
-| | ``service``, a list of one or more |
-| | provider-defined service types. If |
-| | only one service type is |
-| | specified, it may appear without |
-| | list markers (``[]``). |
-+---------------------------------+------------------------------------+
-| ``service_id`` (Optional) | If ``inventory_type`` is |
-| | ``service``, a list of one or more |
-| | provider-defined service ids. If |
-| | only one service id is specified, |
-| | it may appear without list markers |
-| | (``[]``). |
-+---------------------------------+------------------------------------+
-| ``default_cost`` (Optional) | The default cost of an inventory |
-| | candidate, expressed as currency. |
-| | This must be specified if the |
-| | inventory provider may not always |
-| | return a cost. |
-+---------------------------------+------------------------------------+
-| ``required_candidates`` | A list of one or more candidates |
-| (Optional) | from which a solution will be |
-| | explored. Must be a valid |
-| | candidate as described in the |
-| | **candidate schema**. |
-+---------------------------------+------------------------------------+
-| ``excluded_candidates`` | A list of one or more candidates |
-| (Optional) | that should be excluded from the |
-| | search space. Must be a valid |
-| | candidate as described in the |
-| | **candidate schema**. |
-+---------------------------------+------------------------------------+
-| ``existing_placement`` | The current placement for the |
-| (Optional) | demand. Must be a valid candidate |
-| | as described in the **candidate |
-| | schema**. |
-+---------------------------------+------------------------------------+
++-----------------------------+------------------------------------+
+| Key | Value |
++=============================+====================================+
+| ``inventory_provider`` | A HAS-supported inventory |
+| | provider. |
++-----------------------------+------------------------------------+
+| ``inventory_type`` | The reserved words ``cloud`` |
+| | (cloud regions), ``service`` (for |
+| | existing service instances), |
+| | ``vfmodule`` (for vf instances), |
+| | ``nssi`` (for slice subnet |
+| | instances). Exactly one inventory |
+| | type may be specified. |
++-----------------------------+------------------------------------+
+| ``attributes`` (Optional) | A list of key-value pairs, that is |
+| | used to select inventory |
+| | candidates that match *all* the |
+| | specified attributes. The key |
+| | should be a uniquely identifiable |
+| | attribute at the inventory |
+| | provider. |
++-----------------------------+------------------------------------+
+| ``service_type`` (Optional) | If ``inventory_type`` is |
+| | ``service``, a list of one or more |
+| | provider-defined service types. If |
+| | only one service type is |
+| | specified, it may appear without |
+| | list markers (``[]``). |
++-----------------------------+------------------------------------+
+| ``service_id`` (Optional) | If ``inventory_type`` is |
+| | ``service``, a list of one or more |
+| | provider-defined service ids. If |
+| | only one service id is specified, |
+| | it may appear without list markers |
+| | (``[]``). |
++-----------------------------+------------------------------------+
+| ``default_cost`` (Optional) | The default cost of an inventory |
+| | candidate, expressed as currency. |
+| | This must be specified if the |
+| | inventory provider may not always |
+| | return a cost. |
++-----------------------------+------------------------------------+
+| ``required_candidates`` | A list of one or more candidates |
+| (Optional) | from which a solution will be |
+| | explored. Must be a valid |
+| | candidate as described in the |
+| | **candidate schema**. |
++-----------------------------+------------------------------------+
+| ``excluded_candidates`` | A list of one or more candidates |
+| (Optional) | that should be excluded from the |
+| | search space. Must be a valid |
+| | candidate as described in the |
+| | **candidate schema**. |
++-----------------------------+------------------------------------+
+| ``existing_placement`` | The current placement for the |
+| (Optional) | demand. Must be a valid candidate |
+| | as described in the **candidate |
+| | schema**. |
++-----------------------------+------------------------------------+
+
+**Note**
+
+- The demand attributes in the template come from either policy or from
+ a northbound request scope.
.. _examples-1:
**Inventory Provider Criteria**
-+---------------------------------+------------------------------------+
-| Key | Value |
-+=================================+====================================+
-| ``inventory_provider`` | Examples: ``aai``, ``multicloud``. |
-+---------------------------------+------------------------------------+
-| ``inventory_type`` | The reserved word ``cloud`` (for |
-| | new inventory) or the reserved |
-| | word ``service`` (for existing |
-| | inventory). Exactly one inventory |
-| | type may be specified. |
-+---------------------------------+------------------------------------+
-| ``attributes`` (Optional) | A list of key-value pairs to match |
-| | against inventory when drawing |
-| | candidates. |
-+---------------------------------+------------------------------------+
-| ``service_type`` (Optional) | Examples may include ``vG``, |
-| | ``vG_MuxInfra``, etc. |
-+---------------------------------+------------------------------------+
-| ``service_id`` (Optional) | Must be a valid service id. |
-| | Examples may include ``vCPE``, |
-| | ``VoLTE``, etc. |
-+---------------------------------+------------------------------------+
-| ``default_cost`` (Optional) | The default cost of an inventory |
-| | candidate, expressed as a unitless |
-| | number. |
-+---------------------------------+------------------------------------+
-| ``required_candidates`` | A list of one or more valid |
-| (Optional) | candidates. See **Candidate |
-| | Schema** for details. |
-+---------------------------------+------------------------------------+
-| ``excluded_candidates`` | A list of one or more valid |
-| (Optional) | candidates. See **Candidate |
-| | Schema** for details. |
-+---------------------------------+------------------------------------+
-| ``existing_placement`` | A single valid candidate, |
-| (Optional) | representing the current placement |
-| | for the demand. See **candidate |
-| | schema** for details. |
-+---------------------------------+------------------------------------+
++-----------------------------+------------------------------------+
+| Key | Value |
++=============================+====================================+
+| ``inventory_provider`` | Examples: ``aai``, ``multicloud``. |
++-----------------------------+------------------------------------+
+| ``inventory_type`` | The reserved words ``cloud`` |
+| | (cloud regions), ``service`` (for |
+| | existing service instances), |
+| | ``vfmodule`` (for vf instances), |
+| | ``nssi`` (for slice subnet |
+| | instances). Exactly one inventory |
+| | type may be specified. |
++-----------------------------+------------------------------------+
+| ``attributes`` (Optional) | A list of key-value pairs to match |
+| | against inventory when drawing |
+| | candidates. |
++-----------------------------+------------------------------------+
+| ``service_type`` (Optional) | Examples may include ``vG``, |
+| | ``vG_MuxInfra``, etc. |
++-----------------------------+------------------------------------+
+| ``service_id`` (Optional) | Must be a valid service id. |
+| | Examples may include ``vCPE``, |
+| | ``VoLTE``, etc. |
++-----------------------------+------------------------------------+
+| ``default_cost`` (Optional) | The default cost of an inventory |
+| | candidate, expressed as a unitless |
+| | number. |
++-----------------------------+------------------------------------+
+| ``required_candidates`` | A list of one or more valid |
+| (Optional) | candidates. See **Candidate |
+| | Schema** for details. |
++-----------------------------+------------------------------------+
+| ``excluded_candidates`` | A list of one or more valid |
+| (Optional) | candidates. See **Candidate |
+| | Schema** for details. |
++-----------------------------+------------------------------------+
+| ``existing_placement`` | A single valid candidate, |
+| (Optional) | representing the current placement |
+| | for the demand. See **candidate |
+| | schema** for details. |
++-----------------------------+------------------------------------+
**Candidate Schema**
-The following is the schema for a valid ``candidate``: \*
-``candidate_id`` uniquely identifies a candidate. Currently, it is
-either a Service Instance ID or Cloud Region ID. \* ``candidate_type``
-identifies the type of the candidate. Currently, it is either ``cloud``
-or ``service``. \* ``inventory_type`` is defined as described in
-**Inventory Provider Criteria** (above). \* ``inventory_provider``
-identifies the inventory from which the candidate was drawn. \*
-``host_id`` is an ID of a specific host (used only when referring to
-service/existing inventory). \* ``cost`` is expressed as a unitless
-number. \* ``location_id`` is always a location ID of the specified
-location type (e.g., for a type of ``cloud`` this will be an Cloud
-Region ID). \* ``location_type`` is an inventory provider supported
-location type. \* ``latitude`` is a valid latitude corresponding to the
-*location_id*. \* ``longitude`` is a valid longitude corresponding to
-the *location_id*. \* ``city`` (Optional) city corresponding to the
-*location_id*. \* ``state`` (Optional) state corresponding to the
-*location_id*. \* ``country`` (Optional) country corresponding to the
-*location_id*. \* ``region`` (Optional) geographic region corresponding
-to the *location_id*. \* ``complex_name`` (Optional) Name of the complex
-corresponding to the *location_id*. \* ``cloud_owner`` (Optional) refers
-to the *cloud owner* (e.g., ``azure``, ``aws``, ``att``, etc.). \*
-``cloud_region_version`` (Optional) is an inventory provider supported
-version of the cloud region. \* ``physical_location_id`` (Optional) is
-an inventory provider supported CLLI code corresponding to the cloud
-region.
+The following is the schema for a valid ``candidate``:
+
+- ``candidate_id`` uniquely identifies a candidate. Currently, it is
+ either a Service Instance ID or Cloud Region ID.
+- ``candidate_type`` identifies the type of the candidate. Currently, it
+ is either ``cloud`` or ``service``. \* ``inventory_type`` is defined
+ as described in **Inventory Provider Criteria** (above).
+- ``inventory_provider`` identifies the inventory from which the
+ candidate was drawn. \*
+- ``host_id`` is an ID of a specific host (used only when referring to
+ service/existing inventory).
+- ``cost`` is expressed as a unitless number.
+- ``location_id`` is always a location ID of the specified location type
+ (e.g., for a type of ``cloud`` this will be an Cloud Region ID).
+- ``location_type`` is an inventory provider supported location type.
+- ``latitude`` is a valid latitude corresponding to the *location_id*.
+- ``longitude`` is a valid longitude corresponding to the *location_id*.
+- ``city`` (Optional) city corresponding to the *location_id*.
+- ``state`` (Optional) state corresponding to the *location_id*.
+- ``country`` (Optional) country corresponding to the *location_id*.
+- ``region`` (Optional) geographic region corresponding to the
+ *location_id*.
+- ``complex_name`` (Optional) Name of the complex corresponding to the
+ *location_id*.
+- ``cloud_owner`` (Optional) refers to the *cloud owner*
+ (e.g., ``azure``, ``aws``, ``att``, etc.).
+- ``cloud_region_version`` (Optional) is an inventory provider supported
+ version of the cloud region.
+- ``physical_location_id`` (Optional) is an inventory provider supported
+ CLLI code corresponding to the cloud region.
**Examples**
}
}
-**Questions** \* Currently, candidates are either service instances or
-cloud regions. As new services are on-boarded, this can be evolved to
-represent different types of resources.
+**vfmodule candidate**
+
+.. code-block:: json
+
+ {
+ "candidate_id": "d187d743-5932-4fb9-a42d-db0a5be5ba7e",
+ "city": "example-city-val-27150",
+ "cloud_owner": "CloudOwner",
+ "cloud_region_version": "1",
+ "complex_name": "clli1",
+ "cost": 1.0,
+ "country": "example-country-val-94173",
+ "existing_placement": "false",
+ "host_id": "vFW-PKG-MC",
+ "inventory_provider": "aai",
+ "inventory_type": "vfmodule",
+ "ipv4-oam-address": "oam_network_zb4J",
+ "ipv6-oam-address": "",
+ "latitude": "example-latitude-val-89101",
+ "location_id": "RegionOne",
+ "location_type": "att_aic",
+ "longitude": "32.89948",
+ "nf-id": "fcbff633-47cc-4f38-a98d-4ba8285bd8b6",
+ "nf-name": "vFW-PKG-MC",
+ "nf-type": "vnf",
+ "passthrough_attributes": {
+ "td-role": "anchor"
+ },
+ "physical_location_id": "clli1",
+ "port_key": "vlan_port",
+ "region": "example-region-val-13893",
+ "service_instance_id": "3e8d118c-10ca-4b4b-b3db-089b5e9e6a1c",
+ "service_resource_id": "vPGN-XX",
+ "sriov_automation": "false",
+ "state": "example-state-val-59487",
+ "uniqueness": "false",
+ "vf-module-id": "d187d743-5932-4fb9-a42d-db0a5be5ba7e",
+ "vf-module-name": "vnf-pkg-r1-t2-mc",
+ "vim-id": "CloudOwner_RegionOne",
+ "vlan_key": "vlan_key",
+ "vnf-type": "5G_EVE_Demo/5G_EVE_PKG 0",
+ "vservers": [
+ {
+ "l-interfaces": [
+ {
+ "interface-id": "4b333af1-90d6-42ae-8389-d440e6ff0e93",
+ "interface-name": "vnf-pkg-r1-t2-mc-vpg_private_2_port-mf7lu55usq7i",
+ "ipv4-addresses": [
+ "10.100.100.2"
+ ],
+ "ipv6-addresses": [],
+ "macaddr": "fa:16:3e:c4:07:7f",
+ "network-id": "59763a33-3296-4dc8-9ee6-2bdcd63322fc",
+ "network-name": ""
+ },
+ {
+ "interface-id": "85dd57e9-6e3a-48d0-a784-4598d627e798",
+ "interface-name": "vnf-pkg-r1-t2-mc-vpg_private_1_port-734xxixicw6r",
+ "ipv4-addresses": [
+ "10.0.110.2"
+ ],
+ "ipv6-addresses": [],
+ "macaddr": "fa:16:3e:b5:86:38",
+ "network-id": "cdb4bc25-2412-4b77-bbd5-791a02f8776d",
+ "network-name": ""
+ },
+ {
+ "interface-id": "edaff25a-878e-4706-ad52-4e3d51cf6a82",
+ "interface-name": "vnf-pkg-r1-t2-mc-vpg_private_0_port-e5qdm3p5ijhe",
+ "ipv4-addresses": [
+ "192.168.10.200"
+ ],
+ "ipv6-addresses": [],
+ "macaddr": "fa:16:3e:ff:d8:6f",
+ "network-id": "932ac514-639a-45b2-b1a3-4c5bb708b5c1",
+ "network-name": ""
+ }
+ ],
+ "vserver-id": "00bddefc-126e-4e4f-a18d-99b94d8d9a30",
+ "vserver-name": "zdfw1fwl01pgn01"
+ }
+ ]
+ }
+
+**nssi candidate**
+
+.. code-block:: json
+
+ {
+ "candidate_id": "1a636c4d-5e76-427e-bfd6-241a947224b0",
+ "candidate_type": "nssi",
+ "conn_density": 0,
+ "cost": 1.0,
+ "domain": "cn",
+ "e2e_latency": 0,
+ "exp_data_rate": 0,
+ "exp_data_rate_dl": 100,
+ "exp_data_rate_ul": 100,
+ "instance_name": "nssi_test_0211",
+ "inventory_provider": "aai",
+ "inventory_type": "nssi",
+ "jitter": 0,
+ "latency": 20,
+ "max_number_of_ues": 0,
+ "nsi_id": "4115d3c8-dd59-45d6-b09d-e756dee9b518",
+ "nsi_model_invariant_id": "39b10fe6-efcc-40bc-8184-c38414b80771",
+ "nsi_model_version_id": "8b664b11-6646-4776-9f59-5c3de46da2d6",
+ "nsi_name": "nsi_test_0211",
+ "payload_size": 0,
+ "reliability": 99.99,
+ "resource_sharing_level": "0",
+ "survival_time": 0,
+ "traffic_density": 0,
+ "ue_mobility_level": "stationary",
+ "uniqueness": "true"
+ }
**Examples**
- inventory_provider: aai
inventory_type: cloud
-**Questions** \* Do we need to support cost as a function ?
+**Note**
+
+- Cost could be used to specify the cost of choosing a specific
+ candidate. For example, choosing an existing VNF instance can be less
+ costlier than creating a new instance.
Constraints
-----------
+-------------------------------------------+--------------------------+
*Note: Constraint names marked “Deferred” **will not** be supported in
-the initial release of HAS.*
+the current release of HAS.*
Threshold Values
~~~~~~~~~~~~~~~~
**Notes**
-- For ONAP Beijing release the REQUEST_DICT is of the following format as
+- For the current release the REQUEST_DICT is of the following format as
defined by the policy for vim_fit. The REQUEST_DICT is an opaque request
object defined through policy, so it is not restricted to this format. In
- ONAP Beijing release MultiCloud supports the check_vim_capacity using the
+ the current release MultiCloud supports the check_vim_capacity using the
following grammar.
.. code-block:: json
type: inventory_group
demands: [demand_1, demand_2]
-*Note: Only pair-wise groups are supported at this time. If three or
-more demands are specified, only the first two will be used.*
+*Note: Only pair-wise groups are supported at this time. The list must
+have only two demands.*
License
~~~~~~~
Constrain demands according to license availability.
-*Support for this constraint is deferred.*
+*Support for this constraint is deferred to a later release.*
**Schema**
Constrain each pairwise combination of two or more demands by network
requirements.
-*Support for this constraint is deferred.*
+*Support for this constraint is deferred to a later release.*
**Schema**
Constrain one or more demands by network requirements relative to a
specific location.
-*Support for this constraint is deferred.*
+*Support for this constraint is deferred to a later release.*
**Schema**
example, as described by an OpenStack Heat template and operational
environment.
-*Support for this constraint is deferred.*
+*Support for this constraint is deferred to a later release.*
**Schema**
template: http://repository/my/stack_template
environment: http://repository/my/stack_environment
+**Note:**
+
+- The status of the constraint support is of Frankfurt release.
+
Reservations
------------
numbers, operators, and functions, HAS’s solver presently expects a very
specific arrangement.
-Until further notice:
-
- Optimizations must conform to a single goal of ``minimize`` followed
by a ``sum`` operator.
- The sum can consist of two ``distance_between`` function calls, or
**Notes**
-- In the first version, we do not support more than one dimension in
- the optimization (e.g., Minimize distance and cost). For supporting
- multiple dimensions we would need a function the normalize the unit
- across dimensions.
+- We do not support more than one dimension in the optimization
+ (e.g., Minimize distance and cost). For supporting multiple
+ dimensions we would need a function the normalize the unit across
+ dimensions.
Intrinsic Functions
-------------------
- ``file:///path/to/stack_template.yaml``
- ``http://hostname/environment.yaml``
-**Questions**
+**Note**
- If Homing will only be accessed over DMaaP, files will need to be
- embedded using the Homing API request format.
+ embedded using the Homing API request format. This will be a
+ consideration when DMaaP integration happens.
get_param
~~~~~~~~~
Code Review / optf / has.git / commitdiff