es, and service configuration parameters. The definition of a service includes four components: Service data model files define "what" the service is comprised of. They contain pointers to specific VNFs that needed to be instantiated for the service being defined. 2. Business policies and engineering rules define "how" the service should be instantiated. They contain the constraints of the service such as QoS, affinity rules, and security zones. For example, if there is a voice component to the service, the appropriate QoS will be included SO that when the service template is executed, appropriate resources are allo- cated for the service. Dimensioning defines the sizing of the service with respect to virtual resources needed from the cloud infrastructure. 3. Recipes define service policies and cloud platform independent scripts used for deploy- ment and lifecycle management, such as installing VNF software on a VM, provisioning connectivity, auditing the VNFs when they come up, etc. Configuration parameters define the service-specific configurations required to customize the VNFs instantiated for the service. These four components of a service definition are used to define the service templates that can be used as an input to the service orchestrator to automatically instantiate and manage the service. As an example of customization for a service such as VoLTE, the QoS parameters will indicate a specific "Class of Infrastructure" that the service provider needs to offer this service on. In this case, the "Class of Infrastructure" selected will indicate that support for media is required. This will enable appropriate cloud infrastructure resources to be allocated SO that the voice quality will be preserved. The service creation process for virtualized services changes significantly. With every new vir- tualized service being rolled out, the VNF catalog is populated with VNFs that can be reused for future services. Once the VNF catalog is populated with the majority of basic reusable VNFs required to create a serv