1 # [MultiSite-NSD Support](https://osm.etsi.org/gerrit/#/c/160/) #
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.
11 ## Data Model Changes ##
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.
18 list vnf-cloud-account-map {
20 "Mapping VNF to Cloud Account where VNF will be instantiated";
25 "A reference to a vnfd. This is a
27 ../../../../nsd:constituent-vnfd
28 + [nsr:id = current()/../nsd:id-ref]
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";
39 path "/rw-cloud:cloud/rw-cloud:account/rw-cloud:name";
45 "Openmano datacenter name to use when instantiating
51 Constituent VNFR in NSR will be augemented to include datacenter name for individual VNF.
53 augment /nsr:ns-instance-opdata/nsr:nsr/nsr:constituent-vnfr-ref {
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";
60 path "/rw-cloud:cloud/rw-cloud:account/rw-cloud:name";
65 "Openmano datacenter name to use when instantiating
66 the network service.";
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.
74 augment /nsr:ns-instance-opdata/nsr:nsr/nsr:vlr {
77 "The configured cloud account in which the VL is instantiated within.";
79 path "/rw-cloud:cloud/rw-cloud:account/rw-cloud:name";
84 "Openmano datacenter name to use when instantiating
85 the network service.";
90 VNFR will now have new field indicating datacenter where VNF instance is started.
94 "Openmano datacenter name to use when instantiating
95 the network service.";
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.
103 leaf vim-network-name {
105 "Name of network in VIM account. This is used to indicate
106 pre-provisioned network name in cloud account.";
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
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).
125 Relase1 will support NS instances with VNFs running in different datacenters.
127 ## Feature description ##
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.
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.
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.
148 RO API definitions are critical to complete the integration of the feature with RO.
151 Northbound RO API changes to indicate datacenter for individual VNFs.
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
164 - VCA is not functionally impacted.