...
Location | NFVI+VIMs | Code / Vendor | NFVI+VIM requirement |
| DC1 | OpenStack |
| NFV Infrastructure and Virtual Infrastructure Management system that is compatible with ONAP Release 1. |
ONAP Flows:
Modeling vCPE Residential Broadband Services
The vCPE use case consists of several VNFs and networks that can be thought of two types of VNFs / servicesas Resources which fall into two categories:
1. Infrastructure services - These Resources are deployed prior to any customer request for a vCPE service, an instance of vCPE Residential Broadband service. These VNFs and networks are assumed to be up and running and ready to provide their services when a customer order is received.
2. Customer service - consisting of the BRG_Emulator and vG VNFs, deployed on a per customer order basis, utilizing the various infrastructure services.
The Infrastructure service are further sub-categorized:
1.1 General infrastructure - consisting of functions which are required by the vCPE use case but in real life will be used for/by many other services.vDHCP, vAAA, and vDNS belong here.
...
Some of this infrastructure (e.g,. the vGMUX VNF) may be dedicated to supporting vCPE Residential Broadband service instances, and others (e.g., the vDHCP VNF) may provide shared functionality across many service types. We will refer to the latter as "Core Infrastructure".
2. Customer - These Resources are dedicated to a particular customer service instance, and hence are instantiated on a per vCPE Residential Broadband service customer request basis.
Because the Infrastructure Resources support many vCPE Residential Broadband service instances, and because the Core Infrastructure Resources provide support for perhaps many service types, it is appropriate to think of these as collectively providing various underlying "Services" to a higher order customer Service. We will model these Resources accordingly as being comprised of Infrastructure Services which support the vCPE Residential Broadband Customer Service.
Infrastructure Services Modeling
In the "real world", the vDHCP, vAAA, and vDNS+DHCP functions would each be deployed separate of each other as part of true "Core Infrastructure". How, ever, because they do provide a generic supporting function
The specific infrastructure functions will be implemented as two separate services: one for vBNG, another for vG_MUX, in order to allow (not in R1) to scale each separately, and also to enable one vBNG to connect to multiple vG_MUXs as well as one vG_MUX to connect to multiple vBNGs - thus supporting different deployment scenarios of these two functions.
...