Page tree
Skip to end of metadata
Go to start of metadata

Domino's pub/sub architecture is based on labels (see Fig. 1 below). Each Template Producer and Template Consumer is expected to run a local Domino Client to publish templates and subscribe for labels. 

Fig. 1: DOMINO Server provides a pub/sub server. Domino Clients that are template consumers subscribe to the Domino service via labels.

 

As a conscience choice, Domino itself does not interpret what the labels mean. Domino derives labels directly from the normative definitions in TOSCA Simple YAML Profile for NFV.  The initial objective of Domino for the Colorado release is to define "policy" labels and distribute templates to different Domino Clients based on which policy labels they are subscribed to. Based on TOSCA Simple Profile specification, Domino supports policy labels in the following form:

 

<policytype>:properties:<key:value>

 

For instance, let's examine the following Tosca template:


tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0

description: Template for deploying a single server with predefined properties.

metadata:

  template_name: TOSCA NFV Sample Template 

policy_types:

  tosca.policies.Placement.Geolocation:

    description: Geolocation policy

    derived_from: tosca.policies.Placement

topology_template:

  node_templates:

    VNF1:

      type: tosca.nodes.nfv.VNF

      properties:

        id: vnf1

        vendor: acmetelco

        version: 1.0

    VNF2:

      type: tosca.nodes.nfv.VNF

      properties:

        id: vnf2

        vendor: ericsson

        version: 1.0

    VNF3:

      type: tosca.nodes.nfv.VNF

      properties:

        id: vnf3

        vendor: huawei

        version: 1.0

  policies:

    - rule1:

        type: tosca.policies.Placement.Geolocation

        targets: [ VNF1 ]

        properties:

          region: [ us-west-1 ]

    - rule2:

        type: tosca.policies.Placement.Geolocation

        targets: [ VNF2, VNF3 ]

        properties:

          region: [ us-west-1 , us-west-2 ]

 

Domino Server extracts all possible policy labels by exhaustively concatenating key-value pairs under properties section of policy rules to the policy type of these rules:

tosca.policies.Placement.Geolocation:properties:region:us-west-1

tosca.policies.Placement.Geolocation:properties:region:us-west-2

Furthermore, Domino Server iterates over the targets specified under policy rules to generate a set of labels for each target node:

required_labels['VNF1'] = { tosca.policies.Placement.Geolocation:properties:region:us-west-1 }

required_labels['VNF2'] = { tosca.policies.Placement.Geolocation:properties:region:us-west-1 , tosca.policies.Placement.Geolocation:properties:region:us-west-2}

required_labels['VNF3'] = { tosca.policies.Placement.Geolocation:properties:region:us-west-1 , tosca.policies.Placement.Geolocation:properties:region:us-west-2}


When a Template Consuming site (e.g., VNFM or VIM) registers with the Domino Server using Domino Client, it becomes an eligible candidate for template distribution with an initially empty set of label subscriptions. Suppose three different Domino Clients register with the Domino Server and subscribe for some or none of the policy labels such that Domino Server has the current subscription state as follows:
subscribed_labels[site-1] = { } #this is empty set

subscribed_labels[site-2] = { tosca.policies.Placement.Geolocation:properties:region:us-west-1 }

subscribed_labels[site-3] = { tosca.policies.Placement.Geolocation:properties:region:us-west-1 ,  tosca.policies.Placement.Geolocation:properties:region:us-west-2}


Based on the TOSCA example and hypothetical label subscriptions above, Domino Server identifies all the VNFs can be hosted by Site-3, while VNF1 can be hosted by both Site-2 and Site-3. Note that Site-1 cannot host any of the VNFs listed in the TOSCA file.
When a VNF can be hosted by multiple sites, Domino Server picks the site that can host the most number of VNFs. When not all VNFs can be hosted on the same site, the TOSCA file is partitioned into multiple files, one for each site. These files share a common part (e.g, meta-data, policy-types, version, description, etc.) and non-common parts (e.g., VNFs not mapped onto a specific domain are excluded from topology description and policy targets). In the current Domino convention, if a VNF (or any node) does not have a policy rule (i.e., it is not specified as a target in any of the policy rules), that resource is wild carded by default and treated as part of the "common part".  For the example above, no partitioning would occur as all the VNFs are mapped onto site-3; Domino Server simply delivers the Tosca file to Domino Client hosted on site-3. When TOSCA cannot be consumed by a particular site directly, Domino Server can utilize existing translators (e.g., heat-translator) to first translate the template before delivery. 

Fig. 2 shows the block diagram for the processing stages of a published tosca file. Domino Client issues an RPC call publish(tosca file). Domino Server passes the received tosca file to Label Extractor that outputs resource labels. Domain Mapper uses the extracted labels and tosca file to find mappings from resources to domains as well as the resource dependencies. Resource to domain mappings and resource dependencies are utilized to partition the orchestration template into individual resource orchestration templates (one for each domain). If a translation is required (e.g., Tosca to Heat), individual resource orchestration templates are first translated and then placed on a template distribution workflow based on resource dependencies. Message Sender block in the server takes one distribution task at a time from the workflow generator and pushes the orchestration template to the corresponding Domino Client.

Fig. 2: Processing steps at Domino Server

  • No labels