Page Comparison

...

A geographic coordinate expressed as a latitude and longitude.

| Key | Value | |-----------------------------|----------------------------| | latitude | Latitude of the location. | | longitude | Longitude of the location. |

...

An opaque host name that can be translated to a coordinate via an inventory provider (e.g., A&AI).

| Key | Value | |-----------------------------|----------------------------| | host_name | Host name identifying a location. |

...

Common Language Location Identification (CLLI) code(https://en.wikipedia.org/wiki/CLLI_code).

| Key | Value | |-----------------------------|----------------------------| | clli_code | 8 character CLLI. |

...

Support for this schema is deferred.

| Key | Value | |-----------------------------|----------------------------| | iso_country_code | The abbreviated country name associated with the placemark. | | postal_code | The postal code associated with the placemark. | | administrative_area | The state or province associated with the placemark. | | sub_administrative_area | Additional administrative area information for the placemark. | | locality | The city associated with the placemark. | | sub_locality | Additional city-level information for the placemark. | | thoroughfare | The street address associated with the placemark. | | sub_thoroughfare | Additional street-level information for the placemark. |

...

Demand criteria is dependent upon the inventory provider in use.

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 (Optional) | A list of one or more candidates from which a solution will be explored. Must be a valid candidate as described in the candidate schema. | | excluded_candidates (Optional) | A list of one or more candidates that should be excluded from the search space. Must be a valid candidate as described in the candidate schema. | | existing_placement (Optional) | The current placement for the demand. Must be a valid candidate as described in the candidate schema. |

...

Inventory Provider Criteria|

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

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 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 locationid. longitude is a valid longitude corresponding to the *locationid. city (Optional) city corresponding to the location_id. state (Optional) state corresponding to the locationid. country (Optional) country corresponding to the *locationid. region (Optional) geographic region corresponding to the location_id. complex_name (Optional) Name of the complex corresponding to the locationid. ``cloudowner(Optional) refers to the *cloud owner* (e.g.,azure,aws,att, etc.). *cloudregionversion(Optional) is an inventory provider supported version of the cloud region. *physicallocationid`` (Optional) is an inventory provider supported CLLI code corresponding to the cloud region.

Examples

{
	"candidate_id": "1ac71fb8-ad43-4e16-9459-c3f372b8236d",
	"candidate_type": "service",
	"inventory_type": "service",
	"inventory_provider": "aai",
	"host_id": "vnf_123456",
	"cost": "100",
	"location_id": "DLLSTX55",
	"location_type": "azure",
	"latitude": "32.897480",
	"longitude": "-97.040443",
	"city": "Dallas",
	"state": "TX",
	"country": "USA",
	"region": "US",
	"complex_name": "dalls_one",
	"cloud_owner": "att-aic",
	"cloud_region_version": "1.1",
	"physical_location_id": "DLLSTX55",
}

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.

Examples

The following examples illustrate two demands:

• vGMuxInfra: A vGMuxInfra service, drawing candidates of type service from the inventory. Only candidates that match the customer_id and orchestration-status will be included in the search space.
• vG: A vG, drawing candidates of type service and cloud from the inventory. Only candidates that match the customer_id and provisioning-status will be included in the search space.

...

| 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 (Optional) | A list of one or more valid candidates. See Candidate Schema for details. | | excluded_candidates (Optional) | A list of one or more valid candidates. See Candidate Schema for details. | | existing_placement (Optional) | A single valid candidate, 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 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 locationid. longitude is a valid longitude corresponding to the *locationid. city (Optional) city corresponding to the location_id. state (Optional) state corresponding to the locationid. country (Optional) country corresponding to the *locationid. region (Optional) geographic region corresponding to the location_id. complex_name (Optional) Name of the complex corresponding to the locationid. ``cloudowner(Optional) refers to the *cloud owner* (e.g.,azure,aws,att, etc.). *cloudregionversion(Optional) is an inventory provider supported version of the cloud region. *physicallocationid`` (Optional) is an inventory provider supported CLLI code corresponding to the cloud region.

Examples

{
	"candidate_id": "1ac71fb8-ad43-4e16-9459-c3f372b8236d",
	"candidate_type": "service",
	"inventory_type": "service",
	"inventory_provider": "aai",
	"host_id": "vnf_123456",
	"cost": "100",
	"location_id": "DLLSTX55",
	"location_type": "azure",
	"latitude": "32.897480",
	"longitude": "-97.040443",
	"city": "Dallas",
	"state": "TX",
	"country": "USA",
	"region": "US",
	"complex_name": "dalls_one",
	"cloud_owner": "att-aic",
	"cloud_region_version": "1.1",
	"physical_location_id": "DLLSTX55",
}

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.

Examples

The following examples illustrate two demands:

• vGMuxInfra: A vGMuxInfra service, drawing candidates of type service from the inventory. Only candidates that match the customer_id and orchestration-status will be included in the search space.
• vG: A vG, drawing candidates of type service and cloud from the inventory. Only candidates that match the customer_id and provisioning-status will be included in the search space.

demands:
  vGMuxInfra:
  - inventory_provider: aai
    inventory_type: cloud

Questions * Do we need to support cost as a function ?

Constraints

...

service
    service_type: vG_Mux
    attributes:
      customer_id: some_company
      orchestration-status: Activated
  vG:
  - inventory_provider: aai
    inventory_type: service
    service_type: vG
    attributes:
      customer_id: some_company
      provisioning-status: provisioned
  - inventory_provider: aai
    inventory_type: cloud

Questions * Do we need to support cost as a function ?

Constraints

A Constraint is used to eliminate inventory candidates from one or more demands that do not meet the requirements specified by the constraint. Since reusability is one of the cornerstones of HAS, Constraints are designed to be service-agnostic, and is parameterized such that it can be reused across a wide range of services. Further, HAS is designed with a plug-in architecture that facilitates easy addition of new constraint types.

...

Considerations while using multiple constraints Constraints should be treated as a unordered list, and no assumptions should be made as regards to the order in which the constraints are evaluated for any given demand. All constraints are effectively AND-ed together. Constructs such as "Constraint X OR Y" are unsupported. * Constraints are reducing in nature, and does not increase the available candidates at any point during the constraint evaluations.Schemaat any point during the constraint evaluations.

Schema

| Key | Value | |---------------------|-------------| | CONSTRAINT_NAME | Key is a unique name. | | type | The type of constraint. See Constraint Types for a list of currently supported values. | | demands | One or more previously declared demands. If only one demand is specified, it may appear without list markers ([]). | | properties (Optional) | Properties particular to the specified constraint type. Use if required by the constraint. |

constraints:
  CONSTRAINT_NAME_1:
    type: CONSTRAINT_TYPE
    demands: DEMAND_NAME | [DEMAND_NAME_1, DEMAND_NAME_2, ...]
    properties: PROPERTY_DICT

  CONSTRAINT_NAME_2:
    type: CONSTRAINT_TYPE
    demands: DEMAND_NAME | [DEMAND_NAME_1, DEMAND_NAME_2, ...]
    properties: PROPERTY_DICT

  CONSTRAINT_NAME_2:
    type: CONSTRAINT_TYPE
    demands: DEMAND_NAME | [DEMAND_NAME_1, DEMAND_NAME_2, ...]
    properties: PROPERTY_DICT

  ...

...

  ...

Constraint Types

| Type | Description | |---------------------|-------------| | attribute | Constraint that matches the specified list of Attributes. | | distance_between_demands | Geographic distance constraint between each pair of a list of demands. | | distance_to_location | Geographic distance constraint between each of a list of demands and a specific location. | | instance_fit | Constraint that ensures available capacity in an existing service instance for an incoming demand. | | inventory_group | Constraint that enforces two or more demands are satisfied using candidates from a pre-established group in the inventory. | | region_fit | Constraint that ensures available capacity in an existing cloud region for an incoming demand. | | zone | Constraint that enforces co-location/diversity at the granularities of clouds/regions/availability-zones. | | license (Deferred) | License availability constraint. | | network_between_demands (Deferred) | Network constraint between each pair of a list of demands. | | network_to_location (Deferred) | Network constraint between each of a list of demands and a specific location/address. |

...

Each property is documented with a default unit. The following units are supported:

| Unit | Values | Default | |------------|------------------------------|----------| | Currency | USD | USD | | Time | ms, sec | ms | | Distance | km, mi | km | | Throughput | Kbps, Mbps, Gbps | Mbps |

...

Constrain one or more demands by one or more attributes, expressed as properties. Attributes are mapped to the inventory provider specified properties, referenced by the demands. For example, properties could be hardware capabilities provided by the platform (flavor, CPU-Pinning, NUMA), features supported by the services, etc.SchemaPinning, NUMA), features supported by the services, etc.

Schema

| Property | Value | |--------------|-------------------------------------------------------------| | evaluate | Opaque dictionary of attribute name and value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin. |

...

constraints:
  sriov_nj:
    type: attribute
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      evaluate:
        cloud_version: 1.1
        flavor: SRIOV
        subdivision: US-TX
        vcpu_pinning: True
        numa_topology: numa_spanning

Proposal: Evaluation Operators

...

numa_topology: numa_spanning

Proposal: Evaluation Operators

To assist in evaluating attributes, the following operators and notation are proposed:

| Operator | Name | Operand | |--------------|-----------|------------------------------------------------| | eq | == | Any object (string, number, list, dict) | | ne | != | | | lt | < | A number (strings are converted to float) | | gt | > | | | lte | <= | | | gte | >= | | | any | Any | A list of objects (string, number, list, dict) | | all | All | | | regex | RegEx | A regular expression pattern |

...

Constrain each pairwise combination of two or more demands by distance requirements.

Schema

| Name | Value | |--------------|-------------------------------------------------------------| | distance | Distance between demands, measured by the geographic path. |

...

Constrain one or more demands by distance requirements relative to a specific to a specific location.

Schema

Schema

| Property | Value | |--------------|------------------------------------------------------------| | distance | Distance between demands, measured by the geographic path. | | location | A previously declared location. |

...

A service controller plugin knows how to communicate with a particular endpoint (via HTTP/REST, DMaaP, etc.), obtain necessary information, and make a decision. The endpoint and credentials can be configured through plugin settings.

Schema

| Property | Description | |----------------|-----------------------------------| | controller | Name of a service controller. | | request | Opaque dictionary of key/value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin. |

...

A service controller plugin knows how to communicate with a particular endpoint (via HTTP/REST, DMaaP, etc.), obtain necessary information, and make a decision. The endpoint and credentials can be configured through plugin settings.

Schema

, DMaaP, etc.), obtain necessary information, and make a decision. The endpoint and credentials can be configured through plugin settings.

Schema

| Property | Description | |----------------|-----------------------------------| | controller | Name of a service controller. | | request | Opaque dictionary of key/value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin. |

...

Zone categories are inventory provider-defined, based on the demands being constrained.

Schema

| Property | Value | |---------------|-------------------------------------------------------------| | qualifier | Zone qualifier. One of same or different. | | category | Zone category. One of disaster, region, complex, time, or maintenance. |

...

Note: Only pair-wise groups are supported at this time. If three or more demands are specified, only the first two will be used.

License

Constrain demands according to license availability.

Support for this constraint is deferred.

Schema

.

License

Constrain demands according to license availability.

Support for this constraint is deferred.

Schema

| Property | Value | |----------|----------------------------------------------------------| | id | Unique license identifier | | key | Opaque license key, particular to the license identifier |

...

Support for this constraint is deferred.

Schema

| Property | Value | |--------------------------|-----------------------------------------------------------------| | bandwidth (Optional) | Desired network bandwidth. | | distance (Optional) | Desired distance between demands, measured by the network path. | | latency (Optional) | Desired network latency. |

...

Network To Location

Constrain one or more demands by network requirements relative to a specific location.

Support for this constraint is deferred.

Schemaone or more demands by network requirements relative to a specific location.

Support for this constraint is deferred.

Schema

| Property | Value | |---------------|-----------------------------------------------------------------| | bandwidth | Desired network bandwidth. | | distance | Desired distance between demands, measured by the network path. | | latency | Desired network latency. | | location | A previously declared location. |

...

constraints:
  my_access_network_constraint:
    type: network_to_location
    demands: [my_vnf_demand, my_other_vnf_demand]
    properties:
      bandwidth: >= 1000 Mbps
      distance: < 250 km
      latency: < 50 ms
      location: LOCATION_ID

Capabilities

Constrain each demand by its cluster capability requirements. For example, as described by an OpenStack Heat template and operational environment.

Support for this constraint is deferred.

Schema

: < 50 ms
      location: LOCATION_ID

Capabilities

Constrain each demand by its cluster capability requirements. For example, as described by an OpenStack Heat template and operational environment.

Support for this constraint is deferred.

Schema

| Property | Value | |--------------|-------------------------------------------------------------| | specification | Indicates the kind of specification being provided in the properties. Must be heat. Future values may include tosca, Homing, etc. | | template | For specifications of type heat, a single stack in OpenStack Heat Orchestration Template (HOT) format. Stacks may be expressed as a URI reference or a string of well-formed YAML/JSON. Templates are validated by the Heat service configured for use by HAS. Nested stack references are unsupported. | | environment (Optional) | For specifications of type heat, an optional Heat environment. Environments may be expressed as a URI reference or a string of well-formed YAML/JSON. Environments are validated by the Heat service configured for use by Homing. |

...

The service controller plugin knows how to make a reservation (and initiate rollback on a failure) with a particular endpoint (via HTTP/REST, DMaaP, etc.) of the service controller. The endpoint and credentials can be configured through plugin settings.Schemaand credentials can be configured through plugin settings.

Schema

| Property | Description | |----------------|-----------------------------------| | controller | Name of a service controller. | | request | Opaque dictionary of key/value pairs. Values must be strings or numbers. Encoded and sent to the service provider via a plugin. |

...

Optimization definitions can be broken down into three components:

| Component | Key | Value | |-----------|----------------------|---------------------------------------------------------| | Goal | minimize | A single Operand (usually sum) or Function | | Operator | sum, product | Two or more Operands (Numbers, Operators, Functions) | | Function | distance_between | A two-element list consisting of a location and demand. |

...

In this example, properties would be set as follows:

| Key | Value | |------------------|--------------------------| | id | SOFTWAREID | | key | LICENSEKEY | | provider_url | dmaap:///full.topic.name | | cost | 50 |

...