designs/multisite-nsd-support.md

   1 # [MultiSite-NSD Support](https://osm.etsi.org/gerrit/#/c/160/) #
   2
   3 ## Purpose ##
   4 This document describes the functional specification for the
   5 SO module for multi site Network Service that involves supporting NS instances with VNFs running
   6 in different datacenters.
   7
   8 ## Impacted Modules ##
   9 SO, RO, UI
  10
  11 ## Data Model Changes ##
  12
  13 The ns-instance-config node will be modified to add  the following list to specify vim-account
  14 for vnfs. If cloud account and datacenter name is not provided for individual VNF than
  15 ns-instance-config level datacenter name will be used for all VNFs if provided or for those where
  16 below mapping is not provided.
  17
  18     list vnf-cloud-account-map {
  19       description
  20           "Mapping VNF to Cloud Account where VNF will be instantiated";
  21
  22       key "vnfd-id-ref";
  23       leaf vnfd-id-ref {
  24         description
  25             "A reference to a vnfd. This is a
  26             leafref to path:
  27             ../../../../nsd:constituent-vnfd
  28             + [nsr:id = current()/../nsd:id-ref]
  29            + /nsd:vnfd-id-ref";
  30         type yang:uuid;
  31       }
  32
  33       leaf cloud-account {
  34         description
  35             "The configured cloud account where VNF is instantiated within.
  36             All VDU's, Virtual Links, and provider networks will be requested
  37             using the cloud-account's associated CAL instance";
  38         type leafref {
  39           path "/rw-cloud:cloud/rw-cloud:account/rw-cloud:name";
  40         }
  41       }
  42
  43       leaf om-datacenter {
  44         description
  45             "Openmano datacenter name to use when instantiating
  46             the VNF.";
  47         type string;
  48       }
  49     }
  50
  51 Constituent VNFR in NSR will be augemented to include datacenter name for individual VNF.
  52
  53   augment /nsr:ns-instance-opdata/nsr:nsr/nsr:constituent-vnfr-ref {
  54     leaf cloud-account {
  55       description
  56         "The configured cloud account in which the VNF is instantiated within.
  57          All VDU's, Virtual Links, and provider networks will be requested
  58          using the cloud-account's associated CAL instance";
  59       type leafref {
  60         path "/rw-cloud:cloud/rw-cloud:account/rw-cloud:name";
  61       }
  62     }
  63     leaf om-datacenter {
  64       description
  65         "Openmano datacenter name to use when instantiating
  66          the network service.";
  67       type string;
  68    }
  69   }
  70
  71 VLR in NSR will be augemented to include datacenter name. Virtual link will be created in each of
  72 cloud account where constiuent VNFs are instantiated.
  73
  74   augment /nsr:ns-instance-opdata/nsr:nsr/nsr:vlr {
  75     leaf cloud-account {
  76       description
  77         "The configured cloud account in which the VL is instantiated within.";
  78       type leafref {
  79         path "/rw-cloud:cloud/rw-cloud:account/rw-cloud:name";
  80       }
  81     }
  82     leaf om-datacenter {
  83       description
  84         "Openmano datacenter name to use when instantiating
  85          the network service.";
  86       type string;
  87     }
  88   }
  89
  90 VNFR will now have new field indicating datacenter where VNF instance is started.
  91
  92     leaf om-datacenter {
  93       description
  94           "Openmano datacenter name to use when instantiating
  95           the network service.";
  96       type string;
  97     }
  98
  99 VLD will now have a new field vim-network-name to indicate pre-created network name to be
 100 used for this Virtual link. Release 0 provider-network in the VLD was used for this and
 101 this will be changed to use vim-network-name. VLR name will use the vim-network-name if present.
 102
 103       leaf vim-network-name {
 104         description
 105             "Name of network in VIM account. This is used to indicate
 106             pre-provisioned network name in cloud account.";
 107         type string;
 108       }
 109
 110
 111 ## Overview ##
 112
 113 Current implementation in Release 0 allowed the deployment of a Network Service instance
 114  in the datacenter chosen by the user. Specifically the MWC demo covered 4 deployments
 115 and the user decided for every deployment the datacenter where to deploy.
 116 However, it is not possible to span an NS instance across different datacenters on a
 117 single scenario with Release 0(e.g. with some VNFs running in datacenter A and others in
 118 datacenter B).
 119
 120 There are several use cases where a multi-site NS applies, e.g.:
 121 - The deployment of a full core network with several PEs in different datacenters.
 122 - The deployment of VoIP network where some elements are centralized in a datacenter while others
 123   are distributed (e.g. SBC).
 124
 125 Relase1 will support NS instances with VNFs running in different datacenters.
 126
 127 ## Feature description ##
 128
 129 To support running NS instances with VNFs running in different datacenters, UI will support
 130 indicating both the Cloud Account and the Datacenter for each VNF during NS instantiation. This
 131 will be implemented with addition of Cloud account and Datacenter name for each VNF during NS
 132 instantiation as indicated in Data model section.
 133 The cloud account and datacenter name where VNF needs to be instantiated will be populated in both
 134 NSR consituent-vnfs and VNFR and same will be sent to RO as part of instance scenario create.
 135
 136 It is assumed that network interconnecting datacenter is pre-provisioned and has connection
 137 to connect two datacenter sites through this network.Also each Virtual link in NSD
 138 will map to Openamno NSD connections node. It is assumed that RO is expected to reuse
 139 pre-provisioned network in each of applicable cloud accounts or create new networks in applicable
 140 cloud account. Openmano NSD connection node will have type external network and refer to
 141 vim-network-name as Openmano network name and passed in NSD from SO to RO.
 142
 143 ## Inter-Module Dependencies ##
 144 The RO Module Northbound APIs  need to be enhanced to allow specifying datacenter where individual
 145 VNFs should be instantiated.  SO need to pass the datacenter name for VNFs to RO.
 146
 147 ## Risks ##
 148 RO API definitions are critical to complete the integration of the feature with RO.
 149
 150 ## Open Item ##
 151 Northbound RO API changes to indicate datacenter for individual VNFs.
 152
 153 ## Assumptions ##
 154
 155  - It is assumed that the networks interconnecting several datacenters are pre-preprovisioned
 156    ie, there is an E-LAN/E-LINE connection established between the sites for the provider networks
 157    on each location to connect to each other.
 158  - It is also expected that same name is used for these networks connecting sites with each other in Openmano so that
 159    virtual link can use vim-network-name applicable in multiple datacenter networks.
 160  - The datacenter for individual VNFs will be handled as an input in ns-instance-config as part of
 161    the parameters during instantiation.
 162  - There is no change to way networks are exposed by RO ie existing VNFD/NSD Openmano Descriptors
 163    will be used.
 164  - VCA is not functionally impacted.
 165