Figure 1. The main components of a VNF from a vendor perspective

MODA / Information Framework / Business Entity / Resource Domain / Resource Specification ABE / The Firewall Example / Figure 1. The main components of a VNF from a vendor perspective

Project:

Figure 1. The main components of a VNF from a vendor perspective : Object diagram

Created:	5/10/2022 9:37:52 AM
Modified:	5/10/2023 2:24:13 PM
Project:
Author:	Natha Paquette
Version:	1.0.0
Advanced:
ID:	{164DF0DA-56F5-40c2-8BF4-FBC57227A00D}

TR255B Specification Requirements for Resource Functions, in its section 7 gives an example of an atomic ResourceFunction, a Firewall, which exposes several Features (modelled as ConfigurationFeatures) that are to be used in an intent-based deployment approach. The reader is invited to refer to this document for a detailed analysis. The following paragraph is extracted from this document: <ul>
<li>Features</li></ul>
- F1: Layer 2 and 3 - Can Target: IP destination address(es), IP source address(es), TCP/UDP destination port(s), TCP/UDP source port(s), Ethernet MAC destination address, Ethernet MAC source address, Inbound firewall, Outbound firewall (egress) - F2: Work at OSI Layer 4 (stateful firewall) - F3: Work at OSI Layer 7 (application inspection) - F4: Tarpit - Definition of “Tarpit” from Wikipedia: “A tarpit is a service on a computer system (usually a server) that purposely delays incoming connections. The technique was developed as a defense against a computer worm, and the idea is that network abuses such as spamming or broad scanning are less effective, and therefore less attractive, if they take too long. The concept is analogous with a tarpit, in which animals can get bogged down and slowly sink under the surface, like in a swamp.” - F5: Log - F5.C1: Log size in Gbytes <ul>
<li><ul>
<li></li></ul>
</li> </ul>
Further, the following dependencies apply: <ul>
<li>F3 requires F2</li><li>F2 requires F1</li></ul>
In the process of deploying a Firewall RF, the consumer selects the features of his choice. Once selected, the features are mapped to software deployment units (represented as InstalledSoftware in the model) and associated connectivity among the software deployment units. Further, there needs to be a mapping between the software deployment units and the required compute and storage (HostingPlatformRequirement). <ol>
<li>Mapping to Specialized Business Areas</li></ol>
As said above, this proposed model has been generalized and it is expected to be flexible enough to be used for specialized business areas. It can be done in several ways: <ol>
<li>Direct usage of the proposed artefacts, without creating any further derived classes; in that case, it will be instances of the proposed classes of the general model that will directly be created as needed.</li><li>Create more specialized classes inheriting from the proposed classes of the general model, and then using them to create instances as appropriate.</li><li>Make reference to an external model (ex: defined by another SDO) and documenting mapping touch points between the requested classes of the external model and the proposed classes of the general model.</li><li>The instances created will be the ones of the external model, but the mapping touch points rules will be used as guidelines to elaborate appropriate data models (as input to APIs specification).</li></ol>
Below, we illustrate how the example of the ETSI-NFV vCPE scenario document can be supported by using the first style above (direct creation of instances of the proposed classes of the general model). <ol>
<li>Example: ETSI-NFV vCPE scenario</li><li>What can be purchased by a SP from a VNF Vendor</li></ol>
The diagram below illustrates the composition of the virtual Gateway used in scenario 1 (VNF1 from Vendor1) of the vCPE Use Case. It represents the Vendor perspective. Vendor1 sells a package instance called vGW Secure. This package ultimately contains software used to implement 4 functions: Firewall, IP Routing, NAT and DHCP. The SoftwareInformationUnit in the package contains all the appropriate information and data necessary for the deployment on a virtual infrastructure. The deployment process is driven by the deployment structure using Flavors and VDUs. There are two flavors: Flavour1 is made of 2 VDUs: <ul>
<li>VDU1 contains at minimum one software image implementing the 3 functions IP Routing, NAT and DHCP</li><li>(there may be additional software images covering complementary purposes – e.g. tracing or logging features, different versions, etc.…).</li><li>VDU2 contains at minimum one software image implementing the single function Firewall.</li></ul>
Flavour2 is made of only 1 VDU: <ul>
<li>VDU3 that contains at minimum one software image implementing the 4 functions IP Routing, NAT, DHCP and Firewall together.</li></ul>
Additional information will indeed be present, for example: <ul>
<li>to specify the capabilities required by the hosting VM in terms compute/storage/network for each VDU,</li><li>or to specify the affinity rules between VNFCs (associated to the VDUs).</li></ul>
Instances of the “HostingPlatformRequirement” class would be used for that purpose. We did not show it in the figure below, in order to keep things readable. In terms of SID domains, only Product and Resource are used: the vendor sells a Product which is associated to a Resource. (What the vendor will expose in his catalog) Note that this exact representation may also be present in the SP system, in the inventory of vendor’s solutions as acquired, in order to keep track of all the relevant details of the VNF product acquired.