A.1 IMS MRF management and orchestration case study
A.1.2 IMS MRF instance provisioning and configuration
Logical Environment Provision IMS MRF NFVO NFVI MRF-C + MRF-P
Create servers for each VM needed
MRF Storage Provide initial configuration for each
deployed artifact
MRB
Inst Data
• The number of MRB to provision (2 in this use case). • The number of MRF-C+P pairs to deploy (3 in this use case). • The number of MRF storage to deploy (2 in this case). • IP address for S-CSCF external component.
• IP address for app server external component.
NOTE 1: IP addresses for the various instances can be provided in the instantiation definition information or can be constructed dynamically. The latter is assumed in this use case.
NOTE 2: Instantiation definition data can be provided in various possible forms: file, parameters of the request; the exact format would depend on the selected request format.
It is also assumed that the 2 VNFs for MRB, MRF and the IMS MRF VNF Forwarding Graph have been on-boarded as shown in clause A.1.1 IMS MRF instance on-boarding and are present in the VNF and NS catalogues of the NFVO. The overall sequencing of this typical deployment is as follow:
1) NFVO receives the ‘provision IMS MRF' request with the instantiation definition data defined above. 2) NFVO checks that the IMS MRF VNF Forwarding Graph is on-boarded and that the IMS MRF VNFFGD is
present in the VNFG catalogue as well as the MRB and MRF VNFD in the VNF catalogue.
3) NFVO checks the validity of the provided instantiation data against the catalogued VNFDs for MRB and MRF and the IMS MRF VNFGD.
4) NFVO applies the affinity and anti-affinity rules for each VNF and VDU to determine location of instances: a) The 2 MRB instances, MRB-1 and MRB-2 need to be on separate HW resources to guarantee
availability.
b) The 3 instances of MRF-C+P need to be on separate HW resources to guarantee availability. c) The 2 MRF storage instances need to be on separate HW resources to guarantee availability.
d) Each MRF storage instance should be co-located with an MRF instance as per affinity rule to get better performance.
e) Result of the validation is the need for 7 VMs on 3 different HW resources as described earlier. The characteristics needed from each VM are provided by the information in the VNFD.
5) NFVO validates the appropriate resources identified in the previous step are available for fulfilling this request.
Figure A.5: IMS MRF deployment - initial steps
7) NFVO sends a create server command to the NFV infrastructure (for instance a cloud management system (CMS) to create VM-1, hosting instance MRB-1 with information coming from MRB VNF.
NOTE 3: The Cloud Management System might not always be present and if not, NFVO would directly create the VM as shown in the next step.
8) The NFVI in turn sends a request to the hypervisor to create the VM-1 using the provided image. NFVI returns the information on the VM created to NFVO.
9) NFVO sends a create server command to the NFVI to create VM-2, hosting instance MRF-1 with information coming from MRB VNF.
10) NFVI in turn sends a request to the hypervisor to create the VM-2 using the provided image. NFVI returns the information on the VM created to NFVO.
11) NFVO sends a create server command to the NFVI to create VM-3, hosting instance MRF Storage-1 with information coming from MRB VNF.
12) NFVI in turn sends a request to the hypervisor to create the VM-3 using the provided image. NFVI returns the information on the VM created to NFVO.
Figure A.6: IMS MRF deployment steps for HW resource 1 14) Steps 7 to 13 are repeated for the second HW resources to create:
a) VM-4 hosting MRB-2 (role: standby); b) VM-5 hosting MRF-2, (role: active); c) VM-6 hosting MRF Storage 2 (role: slave).
15) Steps 8 & 9 are repeated for the third HW resource to create VM-7 hosting MRF-3 (role: active).
NOTE 4: Steps 7 to 15 are presented as ordered for ease of reading, but creation of servers might be done in any order and might be parallelized.
16) Once the VM is created, its starts and waits for its instantiation definition file.
17) NFVO augments the Instantiation Definition data with data from the VNFD and data obtained as result of the VM creation (e.g. IP addresses, subnet mask, etc.). This global instantiation definition file contains
information on the type of VDU running on each VM (MRB, MRF, MRF Storage), HA role for each instance (active/ standby, master/ slave), IP addresses of the other instances of same type for redundancy, IP addresses of external components (S-CSCF, App Server).
NOTE 5: There might be multiple ways of provide configuration information to the application and this use case is just using a simple one.
18) NFVO then pushes the augmented instantiation definition file to a pre-defined storage location that will be mounted by the corresponding VM. This file will be used to provide the initial configuration of the application,
19) Once all instantiation definition files have been pushed, NFVO provides a successful response to the provision IMS MRF.
20) Each VM reads the instantiation definition file, discovers its VDU type and start the application.
NOTE 6: This case study is using an Instantiation File read by the VM for configuring the VDU. There might be a lot of alternative ways to do the initial configuration of the IMS MRF components, but from a scenario point of view, the end result should be the same.
21) Based on its VDU type and the data from the Instantiation Definition file, the application instance (MRB-1, MRB-2, MRF-1, MRF-2, MRF-3, MRB Storage-1, and MRB Storage-2) synchronizes with each other. For instance, secondary registers with primary.
NOTE 7: Start command might be explicitly sent from NFVO or EM to MRF or MRB or both, or can be implicit, i.e. as soon as it is configured, each component can check with its peer and start in the right order. In this use case, application start is automatic and the application is started when the VM is configured and it automatically configures itself once it got its Instantiation Definition file.
This is illustrated by the following sequence diagram where VM #X is one of the VM instantiated and VNF #X is one of the application artefact instances.
Figure A.7: IMS MRF Deployment Sequence Diagram - Configuration phase