Virtual Network Function (VNF) Definition, Architecture and Design

by · Published · Updated

A Network Function (NF) is an element within a network with well defined external interfaces and functional behavior e.g. DHCP , Firewall, SAE Gateway, MME, eNodeB. Virtual Network Function (VNF) is an software implementation of an Network Function that can be easily deployed on virtual resources such as a Virtual Machine (VM). A service is an offering provided by a Service Provider that is composed of one or more VNFs.

Let me give some example of vEPC (Virtual Evolved Pakcet Core) as a services. If we recall EPC architecture there is network function like MME, Serving gateway, Packet Gateway, HSS and PCRF etc. With the software development if we able to make these network function run on VM machines these becomes VNF and when these all VNF connects to each other with external interface form a vEPC (Virtual EPC).

Some other  examples of VNFs are:

  • Edge Devices: BRAS (Broadband Remote Access Server), vCPE (Virtual Customer P), IP Edge
  • Switching: Broadband Network Gateway (BNG), Carrier Grade Network Address Translator (CG-NAT),routers
  • Tunnelling gateway elements: IPSec/SSL VPN gateways
  • Traffic analysis: DPI, QoE measurement
  • Signalling: SBCs, IMS
  • Application-level optimisation: CDNs, load Balancers
  • Mobile network nodes: HLR/HSS, MME, SGSN, GGSN/PDN-GW, RNC
  • Network-wide functions: AAA server’s policy control, charging platforms
  • Security functions: firewalls, intrusion detection systems, virus scanners, spam protection

VNF Architecture

The internal architecture of a VNF is shown below. It provides more details on the entities and interfaces relevant for the
discussion in the present document while deliberately leaving out those aspects that fall into the infrastructure and management and orchestration domains.

A VNF is a Network Function capable of running on an NFV Infrastructure (NFVI) and being orchestrated by a NFV Orchestrator (NFVO) and VNF Manager. It has well-defined interfaces to other VNFs via SWA1, the VNF Manager, its Element Management (EM), and the NFVI and a well-defined functional behaviour. A VNF may implement a single network entity with interfaces and behavior defined by standards organizations like e.g. 3GPP or IETF, while another VNF may implement groups of network entities. When a group of entities is implemented the internal interfaces between them do not need to be exposed. In both cases the VNFs will provide well-defined interfaces and behavior.

For example, A P-GW network entity may be composed with other network entities like MME and S-GW into an “EPC VNF”. An “EPC VNF” is not restricted to staying compatible to 3GPP-defined interfaces between the internal entities, but will provide the well-defined external interfaces of the group. Likewise, VNFs may implement smaller functional units like TDF or PCEF.

VNF Design Objectives and Guidelines

For a VNF  designed following two factors needs to be taken into account:

  • Functionality – Commonly acceptable functionality is either defined or described in the industry standards e.g. 3GPP MME
  • Atomicity – VNF atomicity has to be guaranteed to ensure that it can be developed, tested and deployed as a separate Virtualized Network Function.

When someone is designing and developing a software to provides a VNF, VNF Providers shall structure the software into software components (implementation view of software architecture) and package these components into one or more images (deployment view of software architecture). In the following, these defined software components are known as VNF Components (VNFCs). VNFs can be implemented with one or more VNFCs and it is assumed, without loss of generality.

How a VNF provider prepares a VNF from a set of VNFCs depends on many factors, e.g. the prioritization of performance, scalability, reliability, security and other non-functional goals, the integration of components from other VNF providers, operational considerations, the existing code base, etc. In general, no two VNF Providers will structure a VNF from the same VNFCs.

Another typical characteristic of VNFCs is that their functionality and interfaces between VNFCs change over time as part of the continuous innovation process. For example, a VNF Provider may decide to improve the VNF’s performance by enhancing the interface between two VNFCs, but these changes do not have effects outside the VNF. As a consequence, VNFCs can in general not be assumed to have interfaces and functional behavior that are meaningful outside of the VNF provider’s software development context. Their interfaces and functional behavior are neither well defined nor necessarily stable from one software release to another.

A VNF is an abstract entity that allows the software contract to be defined, and a VNF Instance is the runtime instantiation of the (design time) VNF. A VNFC is a VNF Providers specific component of a VNF, and VNFC Instances (VNFCIs) are the executing constituents which make up a VNF Instance. In order to instantiate the virtual network function defined by a VNF, VNF Manager create one or more VNFCIs, where each VNFCI is in its own virtualisation container. These VNFCIs, between them, provide the functionality of the VNF, and expose whatever interfaces are provided by that VNF.

The requirements for initial deployment state for a VNF are described in the VNF Descriptor (VNFD), including the connections between VNFCIs which are internal to the VNF, and not visible to external entities at the VNF level. Post-deployment operation capabilities, such as migration of the VMs containing VNFCIs, scale up, scale down, scale in, scale out, changes to network connections, etc., are also described in the VNFD. VNFCIs may have some ability to make changes to the connections between themselves, but those which require changes to the NFVI (other than when exposed, for instance, via hardware drivers) are accomplished by the NFV Management and Orchestration. These entities may derive them automatically, or via directions or requests from the VNF, via the VNFM for that VNF.

Each VNF has exactly one associated VNF Descriptor (VNFD). The functional and non-functional assurances like performance, security, reliability that a VNF provider makes in the VNFD can only be met as long as the VNF’s integrity is maintained. Therefore, a VNF can generally be assumed to be packaged by a single VNF Provider. If the VNF Provider integrates third-party software components into their VNFs’ implementation it is their responsibility to provide a VNF package.

This does not in any way preclude the reuse of software components that are common to two or more VNFs. To reuse such a common component, it would have to be factored out of the original VNFs into a new type of VNF with well-defined interfaces. One of the goals of NFV is to be able to create a structure where key network capabilities can be decoupled as VNFs from the infrastructure on which the VNFs execute so the VNFs can scale when necessary. In order to properly virtualise these types of capabilities they need to be well understood, defined, and catalogued for proper inclusion in service orchestrations.

 

Related Posts:



Tags:

You may also like...