VNFSDN: Integrated VNFs and SDN

• VNFSDN is the integration of Virtual Network Functions (VNFs) and Software Defined Networking (SDN) to create agile, programmable service delivery environments.
• It leverages centralized SDN control and distributed NFV to orchestrate multi-domain service chaining and optimize network resource allocation.
• Research focuses on VNF placement, routing, energy efficiency, and real-time security measures, demonstrating significant performance improvements in 6G networks.

VNFSDN denotes the integration of Virtual Network Functions (VNFs) and Software Defined Networking (SDN) into a programmable service-delivery environment in which SDN supplies centralized control and traffic steering, while NFV supplies software network functions. In the literature, the term appears in two closely related senses: as “VNF in SDN,” referring to SDN-enabled NFV placement and orchestration, especially across multiple SDN domains; and as “Virtual Network Function Service Delivery Network,” a 6G-oriented security framework in which security services are implemented as VNFs and coordinated by SDN in real time (Kaur et al., 2019, Razaque et al., 10 Sep 2025).

1. Definitions and conceptual scope

In SDN-enabled NFV, SDN separates the control plane from the data plane and provides a logically centralized controller that programs packet forwarding devices through southbound interfaces such as OpenFlow, while NFV decouples network functions such as firewalls, NAT, and IDS from proprietary appliances and runs them as software instances on commodity servers. Complex services are represented as Service Function Chains (SFCs), namely ordered sequences of VNFs through which traffic must pass. Within this setting, the SDN controller places VNFs on physical or virtual nodes, computes routes so that flows traverse VNFs in the required order, and allocates CPU, memory, and storage resources to VNFs (Kaur et al., 2019).

Integrated NFV/SDN architectures generalize this model into a broader systems view. The surveyed literature organizes such systems around VNFs, NFV Infrastructure (NFVI), and NFV Management and Orchestration (MANO), while SDN contributes controller-based programmability for connectivity between VNFs, virtual tenant networks, and service function chaining. Within this design space, SDN controllers are placed most commonly in the VIM, but also in the NFVI or as a VNF, and distributed NFV with multiple VIMs and multiple controllers is recurrent in multi-domain and slicing-oriented architectures (Bonfim et al., 2018).

A second, more specific usage defines VNFSDN as a “Virtual Network Function Service Delivery Network” for 6G security. In that formulation, packet filtering, packet capture, IDS/IPS, firewalling, and routing are virtualized as VNFs and orchestrated under SDN control to provide programmable, dynamically adapted security services for high-volume 6G traffic (Razaque et al., 10 Sep 2025).

2. Architectural models

A canonical multi-domain VNFSDN architecture consists of multiple SDN domains, each managed by its own SDN controller and containing OpenFlow-enabled switches or routers together with compute nodes capable of hosting VNFs. Controllers exchange information via east- and west-bound APIs, manage local CPU, memory, and storage, and participate in global decisions that place VNFs across domains in an energy-aware manner. In this model, VNFs are mapped to domain nodes, and QoS is represented implicitly through resource sufficiency rather than explicit per-flow delay or bandwidth constraints (Kaur et al., 2019).

A 6G security-oriented VNFSDN instantiates the controller itself as a VNF. The architecture includes a VNFSDN controller, a VNF pool containing firewall, IDS, packet filter, packet capture, and routing VNFs such as Open vSwitch, network devices including SDN switches and routers, a resource manager or orchestration layer, a cloud or data layer for VNF hosting, and a Python-based VNF implementation platform. Packet ingress occurs at an SDN switch or router; traffic matching controller-installed policies is steered into the VNF pool, especially to the packet filter VNF; and the controller updates routing and security rules through OpenFlow based on statistics and alerts received from VNFs (Razaque et al., 10 Sep 2025).

More generally, integrated NFV/SDN architectures use distributed NFV, multiple VIMs, and multiple SDN controllers to span datacenters, edge sites, and access networks. The literature treats SDN as the mechanism that provides flexible, automated connectivity between VNFs, while NFV supplies the elastic execution substrate. This division is visible in vCPE, mobile core, MEC, and slicing architectures, where service orchestration is separated from infrastructure management, but forwarding and service-chain realization remain controller-driven (Bonfim et al., 2018).

3. Placement, routing, and admission control

A central technical problem in VNFSDN is the joint selection of deployment locations, resource allocations, and traffic paths. In the multi-domain energy-driven formulation, the binary decision variable is

$$\mathbb{X}_{ij} = \begin{cases} 1 & \text{if the } i^{\text{th}} \text{ VNF is deployed on the } j^{\text{th}} \text{ SDN domain},\ 0 & \text{otherwise}, \end{cases}$$

with two objectives: maximize the number of deployed VNFs,

$$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$

and minimize total energy consumption,

$$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$$

subject to unique deployment and CPU, memory, and storage constraints. The model is node-centric: it uses per-VNF–domain energy coefficients $\mathbb{E}_{ij}$, but does not explicitly model link capacities or per-link energy (Kaur et al., 2019).

The same work quantifies the combinatorial growth of the exact problem. The number of binary variables is $\mathrm{M}\times \mathrm{N}$, and the number of constraints is $\mathrm{M}+3\mathrm{N}$. For $\mathrm{M}=100$ and $\mathrm{N}=20$, this yields $2000$ variables and $160$ constraints, motivating a shift from exact ILP to MOEA-based search. In the reported experiments, NSGA-II, NSGA-III, and $$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$0-NSGA-II were evaluated with $$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$1 function evaluations and $$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$2 random seeds; $$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$3-NSGA-II produced the most favorable Pareto front and the lowest elapsed time (Kaur et al., 2019).

Related formulations expand this placement problem into online scaling and distributed service distribution. Online VNF scaling in datacenters models per-server VNF counts $$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$4 and SDN-steered traffic variables $$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$5, with operational and deployment costs, and derives an $$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$6-competitive randomized algorithm for a single service chain and an $$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$7-competitive heuristic for multiple concurrent service chains (Wang et al., 2016). In distributed cloud networking, the NFV service distribution problem is formulated on a cloud-augmented graph and solved by QNSD, which provides an $$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$8 approximation in time $$\mathfrak{F}_1(\mathbb{X}_{ij}) = \max \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij},$$9 for the fractional case and a consolidation-oriented variant for integer resource costs (Feng et al., 2021).

Admission control can also be coupled with embedding and VNF ordering. In network slicing with flexible VNF order, the optimization jointly decides whether a slice is admitted, which VNF order is used, and how virtual nodes and links are embedded onto the physical substrate. The proposed branch-and-bound method combined with A* improves the number of deployable slices by exploiting order flexibility, rather than treating the chain order as fixed a priori (Luu et al., 2024).

4. Chaining mechanisms and forwarding realizations

VNFSDN depends not only on placement but also on how ordered function traversal is realized in the forwarding plane. One realization uses IPv6 Segment Routing. In that model, a VNF chain is represented as

$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$0

where each $$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$$1 is an IPv6 SID carried in the Segment Routing Header. The paper distinguishes SR-aware VNFs, which can receive and possibly modify SRv6-encapsulated packets, from SR-unaware VNFs, which require the NFV node to decapsulate the outer IPv6+SRH header before processing and to re-encapsulate the packet afterward. The Linux-based implementation uses a kernel module, srext, attached to the netfilter PREROUTING hook as an SR/VNF connector, and the software is released as open source (Abdelsalam et al., 2017).

In OpenFlow-enabled cloud environments, the forwarding plane can be optimized further by exploiting non-overlapping match fields and action sets. “Network Function Parallelism” analyzes compiled OpenFlow rules and identifies when functions can be executed in parallel rather than strictly serial order. Implemented on DPDK with OVS and controlled by OpenDaylight, this approach reports a $$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$$2 reduction in latency for service function chaining in an OpenStack cloud network (Chowdhary et al., 2018).

Operator-network studies emphasize that chaining efficiency is strongly affected by the placement substrate. In a Network-enabled Cloud combining one datacenter with NFV-capable network nodes, joint VNF service-chain placement and unsplittable routing are formulated as an ILP minimizing network-resource consumption. The reported results show that a hybrid NeC with a datacenter and NFV-capable nodes can significantly reduce bandwidth usage compared with middlebox-based or DC-only strategies, and that a small number of strategically chosen NFV-capable nodes can approach the performance of a fully NFV-capable substrate (Gupta et al., 2016).

More recent slicing work extends service chaining by permitting flexible VNF order rather than assuming a fixed chain. In that setting, order selection changes the resulting virtual links and bandwidth demands, and branch-and-bound search chooses both the order and the embedding. This shifts VNFSDN from fixed SFC realization toward joint composition-and-embedding (Luu et al., 2024).

5. Security-oriented VNFSDN in 6G networks

In the 6G security formulation, VNFSDN is a programmable security fabric integrating VNFs and SDN to filter, monitor, and adapt to traffic in real time. The security VNFs include a packet filter VNF, a packet capture and saving VNF, Bro (Zeek), Snort, firewall VNFs, and Open vSwitch as a routing or forwarding VNF. The packet filtration logic is expressed as a joint process over

$$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$$3

where packets not conforming to the security state $$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$$4 are blocked and conforming packets are forwarded (Razaque et al., 10 Sep 2025).

The paper formalizes several security metrics. Secure traffic percentage is defined as

$$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$$5

Threat Detection Rate is

$$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$$6

and User Blocking Rate is

$$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$$7

A Redundancy Rate is also defined as

$$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$$8

where $$\mathfrak{F}_2(\mathbb{X}_{ij}) = \min \sum_{i=1}^{\mathrm{M}} \sum_{j=1}^{\mathrm{N}} \mathbb{X}_{ij}\mathbb{E}_{ij},$$9 is total operational time and $\mathbb{E}_{ij}$0 downtime (Razaque et al., 10 Sep 2025).

The empirical evaluation uses OpenDaylight, Mininet, a 6G network emulator on a Linux testbed, Open vSwitch, Bro, Snort, and Python-based packet filter and packet capture VNFs. Across the reported scenarios, VNFSDN improves response time by $\mathbb{E}_{ij}$1 and reduces packet loss by $\mathbb{E}_{ij}$2 relative to no security in a DDoS-mitigation scenario. In traffic management, latency decreases from $\mathbb{E}_{ij}$3 to $\mathbb{E}_{ij}$4, jitter from $\mathbb{E}_{ij}$5 to $\mathbb{E}_{ij}$6, and throughput increases from $\mathbb{E}_{ij}$7 to $\mathbb{E}_{ij}$8. Overall network availability is $\mathbb{E}_{ij}$9 higher than in unsecured networks, and, compared to “prebuilt VNFs,” throughput reaches $\mathrm{M}\times \mathrm{N}$0, response time is $\mathrm{M}\times \mathrm{N}$1 faster, and packet loss is reduced by $\mathrm{M}\times \mathrm{N}$2 (Razaque et al., 10 Sep 2025).

The same source is explicit that AI and machine learning remain conceptual in this framework. It states that ML and AI can significantly improve network security and threat detection capabilities, but provides no specific model, feature set, training procedure, or ML metric. VNFSDN is therefore positioned as the programmable substrate into which ML-based security VNFs could be inserted, rather than as a completed ML security system (Razaque et al., 10 Sep 2025).

6. Lifecycle operations, tooling, and open problems

VNFSDN operation extends beyond static placement to migration, scaling, and software lifecycle management. For VM- and VNF-based migration under SDN, the network problems include IP reachability across subnets, session continuity, bandwidth-intensive state transfer, and QoS constraints on migration paths. The proposed HyperMIP approach controls Mobile IP at the hypervisor, sets up a secure SSH tunnel between home agent and remote hypervisor, redirects incoming traffic through the tunnel, and preserves the original IP address. In the reported experiments, live migration with shared storage can be completed in about $\mathrm{M}\times \mathrm{N}$3 seconds without service interruption, but the paper stresses that link speed must be greater than $\mathrm{M}\times \mathrm{N}$4 for practical live migration (Ibn-Khedher et al., 2015).

Service development and maintenance introduce another layer of VNFSDN complexity. A MANO-aware SDK for SDN/NFV services models services as graphs

$\mathrm{M}\times \mathrm{N}$5

where VNFs are nodes and logical interconnections are edges with annotations such as CPU, memory, storage, bandwidth, and delay constraints. The service package contains references to VNF images, a service graph, and custom control functions such as NFVO and VNFM logic. The SDK supports formal verification, functional verification in emulation or simulation environments, monitor-data analysis, and performance profiling, and illustrates these mechanisms with a secure CDN composed of DPI, Cache, and Router VNFs (Rossem et al., 2018).

At the architectural level, open challenges remain consistent across the literature. The multi-domain energy-driven placement model uses a simplified energy abstraction $\mathrm{M}\times \mathrm{N}$6, omits explicit link energy and dynamic power states, treats QoS through resource feasibility rather than explicit delay or bandwidth formulas, and assumes rather than models east–west controller coordination in detail (Kaur et al., 2019). The 6G security formulation evaluates a single-controller architecture with a small VNF set, acknowledges increased CPU and memory usage as a security trade-off, and leaves AI/ML integration, additional controllers, and real-world 6G deployment for future work (Razaque et al., 10 Sep 2025). Integrated NFV/SDN surveys generalize these issues into broader concerns about multi-domain orchestration, programmability, standardization, security, and scalable controller design (Bonfim et al., 2018).

Taken together, these results present VNFSDN as a family of integrated NFV/SDN systems rather than a single protocol or architecture. Its common structure is the same across multi-domain orchestration, service chaining, 6G security, migration, and DevOps tooling: virtualized functions are instantiated on programmable infrastructure, and an SDN control plane determines how traffic reaches them, in what order, and under which resource and policy constraints.