: Public Boundary

Created:	5/10/2022 9:58:24 AM
Modified:	5/10/2022 10:00:39 AM

Project:
Author:	Natha Paquette
Version:	1.0
Phase:	1.0
Status:	Proposed
Complexity:	Easy
Difficulty:
Priority:
Multiplicity:
Advanced:
UUID:	{442776DC-C90B-4b82-BF8B-0590A0B46074}
Appears In:	Table 1

Scenario 1 vRGW and vSTB are purchased from the same or different vendors as two independent VNFs. The vRGW comes with 4 functions: IPRouting, NAT, DHCP and Firewall. The SP purchasing these two products will get two independent « VNF packages ». From a functional view point each of these two VNFs are made of functions. A VNF Package contains: <ul>
<li>VNFD</li><li>Software Images (or pointers to images)</li><li>Scripts</li><li>Other files.</li></ul>
The package is a signed and immutable artefact. It is provided by the vendor and cannot be changed by the SP. In the VNFD, it is possible to have one or more deployment flavors. A deployment flavor describes a given internal topology of the VNF in terms of deployment. It can be related to support some features like HA, or some specific additional functions. In our case, we assume that for the vRGW (same consideration would go for the vSTB), the vendor has defined 2 flavors illustrated in columns 4 and 5 in the table below: <ul>
<li>Flavor 1: In column 4, the Firewall is associated with one specific VDU (VDU 2) and the 3 others (IP Routing, NAT, DHCP) are associated with a separate VDU (VDU 1).</li><li>(Recall that a VDU is a unit of deployment specifying how to deploy a VNF Component to a single VM. The mapping of the functions to the VNFC/VDU is not described in the VNFD;</li><li>The VDU would have a bootable SW image. The storage desc, attached to the VDU, might also have attached an image (non- bootable).</li><li>SW Images are just something that is part of the package (or have references in the package). The SW Images are pushed to the VIM before instantiation of the VNF). </li><li>Flavor 2: In column 5, the 4 functions are associated with one single VDU (VDU 3) meaning that these 4 functions will be deployed to the same VM.</li></ul>
As a consequence, in scenario 1, there are 3 VDUs: <ul>
<li>(Flavor 1) VDU 1 is associated with a SW image implementing the 3 functions: IP Routing, NAT and DHCP</li><li>(Flavor 1) VDU 2 is associated with a SW image implementing the single function Firewall</li><li>(Flavor 2) VDU 3 is associated with a SW image implementing the 4 functions: IP Routing, NAT, DHCP and Firewall.</li></ul>
 These 2 flavors are the only ones available to the SP for deploying the vRGW. The one shown in the last column (where IP Routing and NAT will be deployed together on one VM and DHCP and Firewall together on another VM) is not possible as it is not part of the Descriptor of the vRGW in the delivered package. To add this 3rd flavor, the SP would have to ask his vendor to change the Descriptor by adding this 3rd flavor, and resubmit the vRGW package. In terms of composition, there are only 2 levels: NS (the vCPE) and VNF/PNF. The VNFC is what is deployed on a VM. It is more than the image, as it includes description of the Virtual Compute (CPU, Memory), of the connection points (interface/ port, LTP…). The image is associated to the VDU and will be running on the VM, but the VNFC is the information that the VNFM maintains on this component for deployment purpose. 1 VM = 1 VNFC, it is possible to have multiple VNFCs on the same host. This is specified by affinity rules: at the VNFD level for rules between VNFCs and at NSD level between VNFs of the same NS.