Release1/multi-site_network_services.md

   1 # Multi-site NS - support of NS instances with VNFs running in different datacenters#
   2
   3 ## Proposer ##
   4 **EUAG**
   5
   6 ## Type ##
   7 **Feature**
   8
   9 ## Target MDG/TF ##
  10 UI, RO, SO
  11
  12 ## Description ##
  13 This feature request is about supporting NS instances with VNFs running in different datacenters.
  14
  15 This feature assumes that the networks interconnecting several datacenters are pre-preprovisioned
  16 (this pre-provision is out of the scope of this feature request).
  17
  18 Current implementation in Release 0 allowed the deployment of a Network Service instance in the
  19 datacenter chosen by the user. Specifically the MWC demo covered 4 deployments and the user decided
  20 for every deployment the datacenter where to deploy.
  21
  22 However, it is not possible to span an NS instance across different datacenters on a single
  23 scenario (e.g. with some VNFs running in datacenter A and others in datacenter B). The workaround
  24 of splitting the NS descriptor and deploy at different datacenters is not valid as it does not
  25 allow to have common NS service primitives.
  26
  27 There are several use cases where a multi-site NS applies, e.g.:
  28
  29 - The deployment of a full core network with several PEs in different datacenters.
  30 - The deployment of VoIP network where some elements are centralized in a datacenter while others
  31 are distributed (e.g. SBC).
  32
  33 In order to have this feature implemented, the following changes are devised:
  34
  35 - In the UI:
  36     - The end user should have the possibility to select for each VNF the specific datacenter where
  37     it will be instantiated.
  38     - If required, the end user should be able to select for each network in the NS the specific
  39     datacenter where it will be instantiated.
  40     - In case of networks spanning across several datacenters (e.g. an E-Line connecting a VNF in a
  41     datacenter to another VNF in a different datacenter), the end user must select for each network
  42     edge which one of the existing datacenter networks has to be used.
  43 - In the RO:
  44     - NS data models should differentiate between the data model for instances and the data model
  45     for templates. The NS instance should allow to specify instance-related parameters for VNFs (in
  46     this case, destination datacenter, but others can be added in the future, e.g. VNF instance
  47     name). Additionally, the NS instance should allow to specify instance-related information for
  48     networks:
  49         - If the network is a single-DC network, i.e. it connects VNFs from the same datacenter,
  50         there is no need to indicate the datacenter where the network will be deployed, since it
  51         will be implicit from the VNFs.
  52         - If the network is an inter-DC network, i.e. it connects VNFs from different datacenters,
  53         the instance related information will include, for each network edge, the existing
  54         datacenter network to be used.
  55     - Database changes to annotate instance-related information, in this case the datacenter (or
  56     datacenters) where it was deployed.
  57     - Changes in northbound API to allow that information
  58 - In the SO:
  59     - NS data models should incorporate a data model for instances, different than the NS data
  60     model for templates, where it should be possible to specify VNF instance-related parameters (in
  61     this case, destination datacenter, but others can be added in the future, e.g. VNF instance
  62     name).
  63     - Connection to RO must be modified accordingly to the changes in RO northbound API.
  64     - Database changes to annotate instance-related information, in this case the datacenter where
  65     it was deployed.
  66
  67 Specs for each module are to be written. For instance, in RO the spec is expected to include the
  68 following devised changes:
  69
  70 - openmano\_schemas.py: changes in schema "instance\_scenario\_create\_schema" to support the
  71 specification of instance-related information per VNF and network.
  72 - nfvo.py: changes in function "create\_instance" to support the new schema and take the actions
  73 accordingly, including the appropriate calls to nfvo\_db functions.
  74 - MySQL DB: changes in "instance\_scenarios", "instance\_vnfs", "instance\_vms" and
  75 "instance\_nets" tables are required. Further investigation is required.
  76 - nfvo\_db: changes in functions to update the previous tables accordingly.
  77 - http\_server.py: changes in http\_post\_instances to take into account the changes in schemas,
  78 nfvo functions and nfvo\_db functions.
  79
  80 ## Demo or definition of done ##
  81 A test case consisting of the deployment of an NS instance with 2 interconnected VNFs (A and B) is
  82 suggested. As a pre-requirement, there must be 2 datacenters (DC1, DC2) interconnected through a
  83 pre-provisioned network visible at RO. As a convention, the network in DC1 will be named
  84 DC1-interDC-net and the network in DC2 will be named DC2-interDC-net.
  85
  86 At instantiation time, in a single transaction (e.g. launched from the GUI or the CLI), the NS
  87 instance must be deployed specifying that VNF A is deployed in DC1 and VNF B in DC2, VNF A is
  88 attached to DC1-interDC-net, and VNF B is attached to DC2-interDC-net.
  89
  90 Information in both RO and SO should be read after the deployment to check validity of the test.