docs/development/overview/feature.overview.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4 ==================
   5 Domino Description
   6 ==================
   7
   8 Domino provides a distribution service for Network Service Descriptors (NSDs) and
   9 Virtual Network Function Descriptors (VNFDs) that are composed using Tosca Simple
  10 Profile for Network Functions Virtualization
  11 (http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html).
  12 Domino service is targeted towards supporting many Software Defined Network (SDN) controllers,
  13 Service Orchestrators (SOs), VNF Managers (VNFMs), Virtual Infastructure Managers (VIMs),
  14 Operation and Business Support Systems that produce and/or consume NSDs and VNFDs.
  15
  16 Producers of NSDs and VNFDs use Domino Service through Service Access Points (SAPs) or End Points (EPs)
  17 to publish these descriptors. Consumers of NSDs and VNFDs subscribe with the Domino Service through
  18 the same SAPs/EPs and declare their resource capabilities to onboard and perform Life Cycle Management
  19 (LCM) for Network Services (NSs) and Virtual Network Functions (VNFs). Thus, Domino acts as a service
  20 broker for NSs and VNFs modeled in a Tosca template.
  21
  22 =============================
  23 Domino Capabilities and Usage
  24 =============================
  25
  26 Labels in Domino
  27 ================
  28
  29 Domino's pub/sub architecture is based on labels (see Fig. 1 below).
  30 Each Template Producer and Template Consumer is expected to run a local Domino Client
  31 to publish templates and subscribe for labels.
  32
  33 .. _fig-label:
  34
  35 .. figure:: ../../etc/domino_pubsub_system.jpeg
  36     :width: 350px
  37     :align: center
  38     :height: 300px
  39     :alt: alternate text
  40     :figclass: align-center
  41
  42     Domino provides a pub/sub server for NSDs and VNFDs
  43
  44 Domino Service does not interpret what the labels mean. Domino derives labels directly from
  45 the normative definitions in TOSCA Simple YAML Profile for NFV. Domino parses the policy
  46 rules included in the NSD/VNFD, form "policy" labels, and determine which resources are
  47 associated with which set of labels. Domino identifies which Domino Clients can host
  48 which resource based on the label subscriptions by these clients. Once mapping of resources
  49 to the clients are done, new NSDs/VNFDs are created based on the mapping. These new
  50 NSDs/VNFDs are translated and delivered to the clients.
  51
  52 Label Format and Examples
  53 =========================
  54
  55 Domino supports policy labels in the following form:
  56
  57 .. code-block:: bash
  58
  59   <policytype>:properties:<key:value>
  60
  61 Orchestrators, controllers, and managers use Domino service to announce their
  62 capabilities by defining labels in this form and subscribing for these labels with
  63 the Domino Server.
  64
  65 For instance a particular VIM that is capable of performing an
  66 affinity based VNF or VDU placement at host machine granularity can specify a label
  67 in the form:
  68
  69 .. code-block:: bash
  70
  71   tosca.policies.Placement.affinity:properties:granularity:hostlevel
  72
  73 When the VIM registers with the Domino Service and subscribed for that label, Domino views
  74 this VIM as a candidate location that can host a VNF or VDU requesting affinity based
  75 placement policy at host machine granularity.
  76
  77 Another use case is the announcement of lifecycle management capabilities for VNFs and
  78 VNF Forwarding Graphs (VNFFG) by different SDN Controllers (SDN-Cs), VNFMs, or VIMs.
  79 For instance
  80
  81 .. code-block:: bash
  82
  83   tosca.policies.Scaling.VNFFG:properties:session_continuity:true
  84
  85 can be used as a label to indicate that when a scaling operation on a VNFFG (e.g., add
  86 more VNFs into the graph) is requested, existing session can still be enforced to go
  87 through the same chain of VNF instances.
  88
  89 To utilize Domino's domain mapping services for virtual network resources (e.g., VNF, VDU,
  90 VNFFG, CP, VL, etc.), a network service or network function request must include
  91 policy rules that are composed of policy types and property values that match to the
  92 label announcements made by these domains. For instance, when a TOSCA template includes a
  93 policy rule with type "tosca.policies.Scaling.VNFFG" and property field
  94 "session_continuity" set as "true" targeting one or more VNFFGs, this serves as the hint
  95 for the Domino Server to identify all the Domain Clients that subscribed the label
  96 "tosca.policies.Scaling.VNFFG:properties:session_continuity:true".
  97
  98 Template Example for Label Extraction
  99 =====================================
 100
 101 Consider the following NSD TOSCA template:
 102
 103 .. code-block:: bash
 104
 105   tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
 106   description: Template for deploying a single server with predefined properties.
 107   metadata:
 108     template_name: TOSCA NFV Sample Template
 109   policy_types:
 110     tosca.policies.Placement.Geolocation:
 111       description: Geolocation policy
 112       derived_from: tosca.policies.Placement
 113   topology_template:
 114     node_templates:
 115       VNF1:
 116         type: tosca.nodes.nfv.VNF
 117         properties:
 118           id: vnf1
 119           vendor: acmetelco
 120           version: 1.0
 121       VNF2:
 122         type: tosca.nodes.nfv.VNF
 123         properties:
 124           id: vnf2
 125           vendor: ericsson
 126           version: 1.0
 127       VNF3:
 128         type: tosca.nodes.nfv.VNF
 129         properties:
 130           id: vnf3
 131           vendor: huawei
 132           version: 1.0
 133     policies:
 134       - rule1:
 135           type: tosca.policies.Placement.Geolocation
 136           targets: [ VNF1 ]
 137           properties:
 138             region: [ us-west-1 ]
 139       - rule2:
 140           type: tosca.policies.Placement.Geolocation
 141           targets: [ VNF2, VNF3 ]
 142           properties:
 143             region: [ us-west-1 , us-west-2 ]
 144
 145 Domino Server extracts all possible policy labels by exhaustively concatenating key-value
 146 pairs under the properties section of the policy rules to the policy type of these rules:
 147
 148 .. code-block:: bash
 149
 150   tosca.policies.Placement.Geolocation:properties:region:us-west-1
 151   tosca.policies.Placement.Geolocation:properties:region:us-west-2
 152
 153 Furthermore, Domino Server iterates over the targets specified under policy rules to generate a set of labels for each target node:
 154
 155 .. code-block:: bash
 156
 157   required_labels['VNF1'] = { tosca.policies.Placement.Geolocation:properties:region:us-west-1 }
 158   required_labels['VNF2'] = { tosca.policies.Placement.Geolocation:properties:region:us-west-1 , tosca.policies.Placement.Geolocation:properties:region:us-west-2}
 159   required_labels['VNF3'] = { tosca.policies.Placement.Geolocation:properties:region:us-west-1 , tosca.policies.Placement.Geolocation:properties:region:us-west-2}
 160
 161 When a Template Consuming site (e.g., VNFM or VIM) registers with the Domino Server using
 162 Domino Client, it becomes an eligible candidate for template distribution with an initially
 163 empty set of label subscriptions. Suppose three different Domino Clients register with the
 164 Domino Server and subscribe for some or none of the policy labels such that the Domino Server
 165 has the current subscription state as follows:
 166
 167 .. code-block:: bash
 168
 169   subscribed_labels[site-1] = { } #this is empty set
 170   subscribed_labels[site-2] = { tosca.policies.Placement.Geolocation:properties:region:us-west-1 }
 171   subscribed_labels[site-3] = { tosca.policies.Placement.Geolocation:properties:region:us-west-1 ,  tosca.policies.Placement.Geolocation:properties:region:us-west-2}
 172
 173
 174 Based on the TOSCA example and hypothetical label subscriptions above, Domino Server identifies
 175 all the VNFs can be hosted by Site-3, while VNF1 can be hosted by both Site-2 and Site-3.
 176 Note that Site-1 cannot host any of the VNFs listed in the TOSCA file. When a VNF can be hosted
 177 by multiple sites, Domino Server picks the site that can host the most number of VNFs. When not
 178 all VNFs can be hosted on the same site, the TOSCA file is partitioned into multiple files, one
 179 for each site. These files share a common part (e.g, meta-data, policy-types, version,
 180 description, virtual resources that are not targeted by any policy rule, etc.). Each site
 181 specific file has also a non-common part that only appears in that file (i.e., virtual
 182 resources explicitly assigned to that site and the policy rules that accompany those virtual
 183 resources.
 184
 185 In the current Domino convention, if a VNF (or any virtual resource) does not have a policy
 186 rule (i.e., it is not specified as a target in any of the policy rules) and it also is not
 187 dependent on any VNF (or any virtual resource) that is assigned to another site, that resource
 188 is wild carded by default and treated as part of the "common part". Also note that currently
 189 Domino does not support all or nothing semantics: if some of the virtual resources are not
 190 mappable to any domain because they are targets of policy rules that are not supported by any
 191 site, these portions will be excluded while the remaining virtual resources will be still be
 192 part of one or more template files to be distributed to hosting sites. When NSDs and VNFDs are
 193 prepared, these conventions must be kept in mind. In the future releases, these conventions can
 194 change based on the new use cases.
 195
 196 For the example above, no partitioning would occur as all VNFs are mapped onto site-3;
 197 Domino Server simply delivers the Tosca file to Domino Client hosted on site-3. When TOSCA
 198 cannot be consumed by a particular site directly, Domino Server can utilize
 199 existing translators (e.g., heat-translator) to first translate the template before delivery.
 200
 201 Internal Processing Pipeline at Domino Server
 202 =============================================
 203
 204 Fig. 2 shows the block diagram for the processing stages of a published TOSCA template.
 205 Domino Client issues an RPC call publish(tosca file). Domino Server passes the received tosca
 206 file to Label Extractor that outputs resource labels. Domain Mapper uses the extracted labels
 207 and tosca file to find mappings from resources to domains as well as the resource dependencies.
 208 Resource to domain mappings and resource dependencies are utilized to partition the
 209 orchestration template into individual resource orchestration templates (one for each domain).
 210 If a translation is required (e.g., TOSCA to HOT), individual resource orchestration templates
 211 are first translated and then placed on a template distribution workflow based on resource
 212 dependencies. Message Sender block in the server takes one distribution task at a time from the
 213 workflow generator and pushes the orchestration template to the corresponding Domino Client.
 214
 215 .. _fig-pipe:
 216
 217 .. figure:: ../../etc/domino_server_processing.png
 218     :width: 400px
 219     :align: center
 220     :height: 350px
 221     :alt: alternate text
 222     :figclass: align-center
 223
 224     Domino Service Processing Pipeline
 225
 226 Resource Scheduling
 227 ===================
 228
 229 Domino Service currently supports maximum packing strategy when a  virtual resource type can
 230 be hosted on multiple candidate sites. Initially, Domino Scheduler identifies virtual resources
 231 that has only one feasible site for hosting. Each such virtual resource is trivially assigned
 232 to its only feasible site. The remaining virtual resources with multiple candidate locations
 233 are sequentially allocated to one of their candidate locations that has the most virtual
 234 resource assignments so far. Note that wildcarded resources are assigned to all sites. To
 235 prevent wildcarding within the current release, (i) all sites must subscribed to a base policy
 236 with a dummy key-value pair defined under the properties tab and (ii) all the independent
 237 resources must be specified as target of that policy in NSD or VNFD file.