Feature Design for: VNF framework

Project Introduction


This marks Stage 2 of VNF support.


Stage 1 focused on  VNF Appliance Integration. You can find a detailed deep-dive on that topic here: 🔗 VNF Appliance Integration Deep Dive

  • CloudStack now supports a dedicated VNF Template type (distinct from regular VM templates) that allows configuration of NICs, management information, access methods, etc. 

  • The “VNF Appliance” concept—deploying a VNF VM in guest network(s) as a network-function device instead of relying purely on the virtual router (VR) built into CloudStack.

  • The UI/UX for VNF covers template registration, NIC mapping, details of the appliance (access/user etc) and verification steps.

  • The approach allows users to bring in familiar network functions (firewall, NAT, load-balancer, VPN, IDS/IPS) in a more flexible software form (VNF) rather than a CloudStack VR.

So the stage for VNF support is already set. The improvements will aim at making it more robust, scalable, manageable, and integrate better into the operator and user workflows.


Later stages might include

  • Service Function Chaining

    • Allow users/admins to define ordered chains: e.g., Firewall → IDS → WAN Optimizer.

    • Auto-generate internal connectivity between VNFs.

  • High Availability (HA)

    • Active-standby VNF pairs with automatic failover.

  • Autoscaling

    • Threshold-based or metric-based scaling for VNFs (e.g., spawn new firewall if bandwidth > X Gbps).

  • Monitoring & Alerts

    • Integrate with Prometheus / CloudStack Telemetry for per-VNF metrics.

  • Networking Enhancements
    • Support VXLAN/NVGRE-based overlay for VNF chaining.
    • Policy-based routing rules (direct specific flows through chosen VNFs).
  • NFV Orchestration Integration

    • Implement ETSI NFV-MANO API compatibility.

    • Enable external controllers (ONAP, OSM) to trigger VNF deployments.

  • VNF Marketplace

    • Curated catalog of certified templates (open-source + commercial).

    • Tagging & version control for VNF templates.

Functional Description


Two architectures are introduced

  • Architecture 1: Direct VNF Management

Data flow

  • Architecture 2: Broker-based VNF Management

Data flow



Advantages of a VNF Framework in Apache CloudStack


1. Unified Management for Multiple VNF Vendors

  • Manage different VNF appliances (Fortinet, Palo Alto, F5, VyOS, HAProxy, etc.) via a single CloudStack API and UI.

  • Each vendor’s specifics (SSH commands, REST APIs, etc.) are handled by adapters or brokers.

  • Reduces operator complexity — no need to learn each VNF’s proprietary interface.

2. Lifecycle Management (Full automation)

  • Automates all lifecycle stages:

    • Deploy

    • Configure / Update

    • Upgrade

    • Rollback

    • Monitor / Health

  • Replaces ad-hoc scripts with a consistent framework.

  • Makes VNFs “first-class citizens” in CloudStack — just like VMs, Networks, or Volumes.

3. Pluggable Architecture (Extensibility)

  • Vendors or integrators can easily add a new VNF Plugin without modifying core CloudStack.

  • Supports both:

    • Direct adapters (CloudStack ↔ VNF)

    • Broker adapters (CloudStack ↔ VNF Broker ↔ VNF)

  • Keeps CloudStack clean while allowing vendor flexibility.

4. API and GUI Integration

  • VNFs can be controlled via CloudStack API, UI, or automation tools (Terraform, Ansible).

  • Operators get consistent UX:

    • Apply configuration

    • View current state and health

    • Upgrade firmware/images

    • Rollback or reapply configs

  • GUI can show VNF topology and service chain visually.

5. Supports Hybrid Management (Direct or Brokered)

  • Can talk directly to VNFs or go through a VNF Broker that integrates deeper (e.g., via SDKs or vendor APIs).
  • CloudStack remains vendor-neutral — operators can choose what fits their environment.

Non-Functional Requirements


VNF templates are ready


User Interface

to be added.

Milestones


MilestonePlanned dateActual date
1Start development

2main Development is done

3dev testing is done

4add marvin/unit test

5Final dev review

6pass over to QA

7QA testing is done

Glossary



Database Changes


References