Listed below are some Points of Contact (PoCs) for United States (US) government organizations and non-government organizations including open-source communities, standards development organizations (SDOs), and software development organizations (SWDOs) engaged in developing, analyzing or evaluating software or hardware employing Software-Defined Networking (SDN) or associated technologies. 

An SWDO is an organization formed by one or more interested individuals, non-commercial organizations and commercial companies. SDOs are similar to SWDOs in many organizational aspects, but their purposes are quite different. The purpose of an SDO is to develop, publish and maintain standards and policies within a defined scope of responsibility. One purpose of an SWDO is to develop, publish, maintain, and possibly even promote the use of software (or devices and related software) within a defined scope of responsibility, and (for a few SWDOs) another purpose is to function as an SDO for that software. An SWDO may have additional purposes that are not limited to software development, such as hardware development. The scope of any SDO or SWDO may be self-defined or their scope may be defined by a higher level organization.

These PoCs may be used to discover and ask questions about their past results, current activities, and future directions. This list is not intended to be either authoritative or exhaustive.

Reminder: This information is not to be used for commercial purposes, such as promotion of commercial products or services. 

SDN Points of Contact
Name	Website			Contact
US Government
American Council for Technology-Industry Advisory Council (ACT-IAC)	https://www.actiac.org/			ACT-IAC [at] actiac.org
IT Sector Coordinating Council (IT SCC)	https://www.it-scc.org/			https://www.it-scc.org/contact.html
National Security Telecommunications Advisory Committee (NSTAC)	https://www.cisa.gov/nstac			nstac [at] cisa.dhs.gov
Non-Government Organizations
Open-Source Communities
Anuket under the auspices of The LF	https://anuket.io/ [previously Common NFVi Telco Taskforce (CNTT) and Open Platform for NFV Project, Inc. (OPNFV)] (See announcement.)			https://anuket.io/contact/
The Ceph Foundation under the auspices of The LF	https://ceph.com/			ceph-community [at] lists.ceph.com
Central Office Re-Architected as a Datacenter (CORD) under the auspices of The LF	https://opennetworking.org/cord/			info [at] opennetworking.org
Cloud Foundry Foundation under the auspices of The LF	https://www.cloudfoundary.org/the-foundry/			Contact Us
Cloud Foundry Foundation active projects	https://github.com/cloudfoundry			community
Cloud Native Computing Foundation (CNCF) under the auspices of The LF	https://www.cncf.io/			https://www.cncf.io/about/contact/
Data Plane Development Kit (DPDK) under the auspices of The LF	http://dpdk.org/			admin [at] dpdk.org
The Disaggregated Enterprise Network Technology (DENT) project under the auspices of The LF	https://dent.dev/			https://dent.dev/join
Fast Data Project (FD.io) under the auspices of The LF	https://fd.io/			info [at] fd.io
flexiWAN	https://flexiwan.com/			click on CONTACT US
Gohan	https://gohan.cloudwan.io/			info_cloudwan [at] ntti3.com
Grafeas ("Scribe" in Greek)	https://grafeas.io/			https://groups.google.com/forum/#!forum/grafeas-users
Kata Containers under the auspices of the Open Infrastructure Foundation	https://katacontainers.io/			mailman [at] lists.katacontainers.io
Knative	https://knative.dev			Knative users Group
The Linux Foundation (The LF) (See Note 1 below)	https://www.linuxfoundation.org/			info [at] linuxfoundation.org
The Linux Foundation Europe	https://linuxfoundation.eu/			Info (at) linuxfoundation.eu
LF Projects, LLC	Home - LF Projects, LLC			manager [at] lfprojects.org
LF EDGE, under the auspices of The LF	https://www.lfedge.org/ (umbrella organization for projects including Akraino, Alvarium, Baetyl, EdgeX, eKupier, Foundry, Fledge, Home Edge, Open Glossary for Edge Computing, Open Horizon, Project EVE, Secure Device OnBoard and State of the Edge)			Complete form on Contact Us webpage and click on submit
NEPHIO Project, under the auspices of The LF	https://nephio.org/			Complete form on Contact webpage and click on SUBMIT
Netconf Working Group, under the auspices of the Internet Engineering Task Force (IETF)	https://trac.ietf.org/trac/netconf/wiki			netconf [at] ietf.org
Open Baton	https://openbaton.github.io/			info [at] openbaton.org
Open Compute Project (OCP) under the auspices of The LF	http://www.opencompute.org/			opencompute-networking [at] lists.opencompute.org
Open Container Initiative (OCI) under the auspices of The LF	https://www.opencontainers.org/			info [at] opencontainers.org
Open Cybersecurity Schema Framework	https://github.com/ocsf/			Read the OCSF Contribution Guide
Open Distributed Infrastructure Management (ODIM) under the auspices of The LF	https://odim.io			odim-general [at] lists.odim.io
OpenFastPath Foundation	https://www.OpenDataPlane.org/			odp [at] lists.opendataplane.org
Open Modeling and Simulation Architecture (OpenMSA)	https://ubiqube.com/openmsa/			OpenMSA, a Google group (Subscription required)
Open Network Automation Platform (ONAP) under the auspices of The LF	https://www.onap.org/ (a merger of the Open-O project and the AT&T Enhanced Control, Orchestration, Management, and Policy [ECOMP] platform)			At the bottom of the opening page, fill in the Stay Connected form and click on SIGN UP
Open-Source Hybrid IP/SDN (OSHI)	http://netgroup.uniroma2.it/twiki/bin/view/Oshi (OSHI is defunct. Website is for reference.)			oshi-list [at] googlegroups.com
Open-Source MANagement and Orchestration (MANO), under the auspices of the ETSI	https://osm.etsi.org/			OSMsupport [at] etsi.org
Open-Source Network Operating System (ONOS) under the auspices of The LF	https://opennetworking.org/onos/			info [at] opennetworking.org
Open-Source Security Foundation (OpenSSF) under the auspices of The LF	https://openssf.org/			https://openssf.org/getinvolved/
Open vSwitch under the auspices of The LF	http://openvswitch.org/			discuss [at] openvswitch.org
OpenConfig	http://www.openconfig.net/			https://groups.google.com/forum/?hl=en%23!forum/netopenconfig#!forum/os-openconfig
The OpenDaylight (ODL) Project under the auspices of The LF	https://www.opendaylight.org/			info [at] opendaylight.org
OpenFlowSec.org	http://www.openflowsec.org/			click on Contact Us button
OpenSwitch (OPX) Network Operating System (NOS) under the auspices of The LF	https://www.openswitch.net/			mailman [at] lists.openswitch.net
Platform for Network Data Analytics (PNDA) under the auspices of The LF	http://pnda.io/			info [at] pnda.io
Post-Quantum Cryptography Alliance (P-QCA) under the auspices of The LF	https://pqca.org			https://pqca.org/#contact
Project Floodlight	https://floodlight.atlassian.net/wiki/home			https://groups.io/g/floodlight
P4 Language Consortium under the auspices of The LF	https://p4.org			p4-discuss [at] lists.p4.org
RouteFlow Project	https://routeflow.github.io/RouteFlow/			https://groups.google.com/group/routeflow-discuss/topics
Streaming Network Analytics System (SNAS) under the auspices of The LF	https://snas.io/			https://www.snas.io/aboutus/
Tungsten Fabric under the auspices of The LF	https://tungsten.io/			https://groups.google.com/forum/#!forum/tungsten-users     (In Mar 2018 Opencontrail finalized a merger with Tungsten Fabric)
Zuul under the auspices of the Open Infrastructure Foundation	https://zuul-ci.org/			zuul-announce [at] lists.zuul-ci.org
SDO Points of Contact
The 3rd Generation Partnership Project (3GPP)	https://www.3gpp.org/			info [at] 3gpp.org
The European Telecommunications Standards Institute (ETSI) (See Note 1 below)	https://www.etsi.org/			info [at] etsi.org
Industry Specifications Group (ISG) for Network Functions Virtualisation (NFV), under the auspices of ETSI	https://www.etsi.org/technologies/nfv			ISGsupport [at] etsi.org
Institute of Electrical and Electronic Engineers (IEEE) Software Defined Networks Initiative	https://sdn.ieee.org/			https://sdn.ieee.org/about
Interface to the Routing System (I2RS), under the auspices of the IETF	https://datatracker.ietf.org/wg/i2rs/charter/			i2rs [at] ietf.org
ITU-T SG-13: Future networks, with focus on IMT-2020, cloud computing and trusted network infrastructures, under the auspices of the International Telecommunication Union – Telecommunication Standardization Sector	https://www.itu.int/en/ITU-T/studygroups/2017-2020/13/Pages/default.aspx			tsbsg13 [at] itu.int
Network Services Interface Working Group	https://www.redmine.org/			Help Forums
Network Services Management Work Group, under the auspices of the Distributed Management Task Force, Inc.	https://www.dmtf.org/standards/nsmwg			https://www.dmtf.org/contact/working-groups Fill in the Contact form. In the Working Group -Select- box, choose the "Network Services Management Working Group". After completing the Contact form, click on Submit
Small Cell Forum	https://www.smallcellforum.org/			Click on Get In Touch, fill out the contact form, and click on SUBMIT FORM
SWDO Points of Contact
Anuket under the auspices of The LF	https://anuket.io/ [previously Common NFVi Telco Taskforce (CNTT) and Open Platform for NFV Project, Inc. (OPNFV)] (See announcement.)			https://anuket.io/contact/
Centre of Excellence in Next Generation Networks (CENGN)	https://www.cengn.ca/			info [at] cengn.ca
Groupe Spécial Mobile (GSM) Association (GSMA)	https://www.gsma.com/			On the Contact Us web page, complete the form, check the Email Consent box, and click on SUBMIT
Mplify Alliance (which was known as the Metro Ethernet Forum (MEF) until Jun, 2025)	https://www.mplify.net/			At the top of the home page of the Mplify Alliance website, click on Contact Us
Open Networking Foundation (ONF) (See note 2 below.)	https://www.opennetworking.org/			https://www.opennetworking.org/contact/
Open Networking User Group (ONUG)	https://www.onug.net			Fill out the Contact form and click on Submit
Open Radio Access Network (O-RAN)	https://www.o-ran.org/			At the bottom of the opening page, fill in the Get Latest News and Updates form and click on SIGN UP
Software-Defined Perimeter (SDP) and Zero Trust Working Group, under the auspices of the Cloud Security Alliance	https://cloudsecurityalliance.org/research/working-groups/software-defined-perimeter-and-zero-trust/			info [at] cloudsecurityalliance.org

 Note 1: The ETSI and The LF signed a Memorandum of Understanding in April, 2019, enabling industry standards and open-source collaboration.

 Note 2: The ONF announced in Dec 2023 that it is merging its portfolio of open source networking projects into The LF as independent projects.

The IEEE SDN Initiative maintains a collection of PoCs for open-source communities, SDOs, and SWDOs (which they call Hybrid Standard/Open-Source organizations) available here, while the IEEE SDN Wiki maintains a collection of PoCs for SDOs available here. The opensource.com website maintains a collection of PoCs for open-source communities. Another collection of PoCs which includes open-source communities and SWDOs engaged in developing, analyzing and evaluating SDN or associated technologies is available here (registration required). A survey of international SDOs efforts to develop, analyze and evaluate standards for SDN and associated technologies is available here.

The materials collected here document the experiences of those who have:

• deployed a new or updated an existing networking infrastructure including Software-Defined Networking (SDN) or associated software architectures such as Network Functions Virtualization (NFV).
• developed or updated networking devices, software, or procedures including support for SDN or associated software architectures such as NFV and Virtual/Virtualized Network Functions (VNF).

While not limited to the topic of deploying SDN, the article 8 Lessons from 20 Years of Hype Cycles still provides lessons that are relevant to the topic of deploying SDN technology.

Training and testing materials for those already using or planning to use SDN or associated software architectures are also provided.

No attempt has been made to extract lessons learned. Instead, original documents are referenced so that the lessons learned can be understood in context. A best-practices document describes actions or practices that are known to produce good outcomes when followed..

Materials listed below come from a wide variety of sources, including conference presentations, research papers, industry studies, commercial provider publications, and other websites. Material was included because of its informational content, rather than to promote interest in SDN and associated software architectures or any particular company. The lessons learned material is organized as follows:

1. Networking customers (e.g., government, industry, educational or research organizations)
2. Service providers (e.g., Internet Service Providers, internet exchange operators, or wireless carriers)
3. Data center and cloud service operators, content providers (e.g., Internet Content Providers or Over-The-Top content providers)
4. Commercial providers (i.e., companies that manufacture, sell or support networking devices, functions, software or services)
5. Groups (open-source communities, standards development organizations and trade groups)
6. Websites, Small-Medium Businesses [SMB], and individuals (researchers and developers)

and the training and testing materials are organized as follows:

1. Training Resources (presentations, papers, books, hands-on tutorials, software tools)
2. Testing Resources (measurement, methodology, test beds, testing, troubleshooting)

In alphabetical order within each category, each entry provides a source, date of creation and title with a link to the web address of the presentation, paper, video, website, or book.

1. Networking customers.

Source	Date	Title
Cornell University	2013	Experience with 3 SDN controllers in an enterprise setting
Department of Energy	2015	ESnet’s (100G) SDN Testbed
		Software Defined Exchanges: The New SDN?
Duke University	2015	Duke's SDN Journey
	2016	ConCERNing SDN (review of lessons learned designing, building, and operating an intercampus network)
Florida International University	2015	FELIX: FEderated Test-beds for Large-scale Infrastructure eXperiments
Global Environment for Networking Innovation (GENI)	2014	GENI: A federated testbed for innovative network experiments (NOTE: Registration required)
Google	2012	Openflow@Google (video available here)
	2013	B4: Experience with a Globally-Deployed Software Defined WAN (video available here)
	2015	Software Defined Networking at Scale
	2016	Maglev: A Fast and Reliable Software Network Load Balancer
	2016	A Purpose-built Global Network: Google's Move to SDN
	2016	Lessons Learned from B4, Google's SDN WAN (video available here)
Internet2	2012	Internet2 Innovation Platform FAQ
	2015	Challenges of supporting SDN in production
	2015	Internet2 Implements Open-Source SDN Networking OS
Internet 2 & Open Network Operating System (ONOS)	2015	Global ONOS and SDN-IP deployment
	2015	Internet2 Implements First Large-scale Deployment of ONOS in Live Network
Lawrence Berkeley National Laboratory	2015	SDN Theory and Best-practices
Microsoft	2014	Real-World SDN: 5 Lessons: Lesson 1: Management Up Front Lesson 2: Conquer the Enemy Within Lesson 3: Focus on the App Lesson 4: Plan for a Hybrid Cloud Lesson 5: Demand More From Vendors
Stanford University	2013	Maturing of OpenFlow and Software-Defined Networking through Deployments

 

1. Service providers.

Source	Date	Title
Accedian Networks	2016	NFV and SDN Lessons from vCPE Deployments (video available here)
American Telephone and Telegraph (AT&T)	2013	AT&T Domain 2.0 Vision White Paper
	2017	OpenContrail as SDN controller for NFV infrastructure in AT&T network
CenturyLink, Inc.	2014	Real World Lessons of SDN and NFV
Ciena Corporation	2020	Overcoming Network Virtualization Barriers
Deutsche Telekom AG	2013	TeraStream – A Simplified Service Delivery Model
Defense Information Systems Agency (DISA)	2018	Why DISA has embraced SDN for the Pentagon
Fujitsu Network Communications, Inc.	2014	Software-Defined Networking for the Utilities and Energy Sector
Global Environment for Networking Innovations (GENI)	2014	Workshop on Prototyping and Deploying Experimental Software Defined Exchanges (SDXs) (in particular, the Workshop Outbrief)
Huawei	2015	Upgrading Your System – a Telco User Perspective
	2016	Lessons Learned - Cloud Transformation in the Enterprise
Network Operations and Internet SEcurity (NOISE), Princeton	on-going	SDX: Software Defined Internet Exchange
NTT America - An NTT Communications Company	2013	SDN: Lessons Learned from a Top IP Provider
Openwave Mobility	2017	6 lessons for mobile operators moving to NFV
Pacific Northwest National Laboratory (PNNL)	2022	Software-defined Networking for Energy Delivery Systems (SDN4EDS): An Architectural Blueprint – Final Report
Research and Education Advanced Network New Zealand Ltd (REANNZ) & Wellington Internet Exchange (WIX)	2014	Cardigan: SDN Distributed Routing at an Internet Exchange
Rothenberg, Chua, et al	2014	Cardigan: When Open-Source Meets Network Control Planes
SKT, Viva Kuwait, and ZTE	2018	Migration from Physical to Virtual Network Functions – Best-practices and Lessons Learned
Verizon	2016	Lessons Learned: Deploying NFV infrastructure at Verizon (video)  Notes on the video
	2016	Verizon Network Infrastructure Planning: SDN-NFV Reference Architecture (technical details)

 

1. Data center and cloud service, content providers.

Source	Date	Title
Alibaba	2015	Hybrid Cloud Networks: OpenFlow/VxLAN Practice (video)
Amazon
ACMQueue	2006	A Conversation with Amazon CTO Werner Vogels
High Scalability blog entry	2007	Amazon Architecture
eBay inc.	2015	SDN Networks at web scale (video)
Facebook	2015	What Facebook's newest data center can teach us
	2015	Facebook completes Chef DevOps migration, shares lessons
Google	2014	Enter the Andromeda zone – Google’s Cloud Platform (video available here)
	2015	A look inside Google’s Data Center Networks (video available here)
Intel Corporation	2014	Adopting Software-Defined Networking in the Enterprise
LinkedIn	2016	Project Falco: Decoupling Switching Hardware and Software
Microsoft	2013	Brain-Slug: A BGP-only SDN for Large Scale Data Centers
	2013	SDN in the Public Cloud: Windows Azure
	2014	Windows Azure: Scaling SDN in the Public Cloud (video)
	2015	Microsoft Azure: SDN in a Hyperscale Cloud (video)
	2016	Software for Open Networking in the Cloud (SONiC) (Note: Since Apr, 2022, SONiC has been under the auspices of the Linux Foundation (The LF)
	2017	VFP: A Virtual Switch Platform for Host SDN in the Public Cloud
	2018	Azure Accelerated Networking: Smart NICs in the Public Cloud
Network Heresy	2013	Network Virtualization and the End-to-End Principle
Openstack	2015	Building a Secure Multi-tenant Cloud for SaaS Applications (video)
PayPal	2015	PayPal VP on OpenStack deployment benefits and burdens
VMWare and International Computer Science Institute (ICSI)	2014	Network Virtualization in Multi-tenant Datacenters
Yahoo!	2012	SDN in Warehouse Scale Datacenters v2.0 (video available here)

 

1. Commercial providers.

Source	Date	Title
Affirmed Networks (A Microsoft company)	2018	Lessons Learned on the NFV Front Lines
DataYard	2014	Building Mission Critical Cloud Infrastructure: Lessons Learned At Scale
Deloitte Development LLC.	2015	Operationalizing SDN and NFV Networks
Ericsson	2014	CenturyLink: Competitive Innovation
Nicira Networks	2012	SDN: What I’ve Learned
Cisco, NetApp, & Red Hat	2014	Considerations and Lessons Learned Deploying OpenStack
HP, Intel, & WindRiver	2013	Practical Implementation of SDN & NFV in the WAN
Metaswitch Networks (A Microsoft company)	2016	Summary Lessons from Deploying NFV
Packet Design	2015	How we failed at OpenStack
Red Hat	2016	Lessons Learned from a Large-Scale Telco OSP+SDN Deployment (video available here, CI means "continuous integration"))
	2017	Best-practices for successfully deploying NFV
Sandvine	2015	From hardware to NFV: lessons learned in deploying an OpenStack reference at scale (video)

 

1. Groups.

Source	Date	Title
Alliance for Telecommunications Industry Solutions (ATIS)	2013	Operational Opportunities and Challenges of SDN/NFV Programmable Infrastructure © 2013 by Alliance for Telecommunications Industry Solutions. ALL RIGHTS RESERVED.
American Council for Technology-Industry Advisory Council (ACT-IAC)	2017	Software Defined Networking and Network Function Virtualization
	2018	Cloud Migrations – Lessons Learned (cloud migration case studies from 11 representative Federal government agencies)
Cloudify.co	2018	Why 70% of NFV and Digital Transformation Projects Fail
Groupe Spécial Mobile (GSM) Association (GSMA)	2020	Migration from Physical to Virtual Network Functions – Best-practices and Lessons Learned Version 0.1
ICSI and UC Berkeley	2012	NOX, POX, and Lessons Learned
Institute of Electrical and Electronics Engineers (IEEE) Future Directions Committee (FDC)	2014	Software-Defined Networks for Future Networks and Services: Main Technical Challenges and Business Implications
	2014	A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks
Mplify Alliance standards development organization (known as the Metro Ethernet Forum (MEF) until Jun, 2025)	beginning in 2016	Carrier Ethernet
Network Functions Virtualization (NFV) European Telecommunications Standards Institute (ETSI) Industry Specifications Group (ISG)	2015	ETSI Group Specification (GS) NFV-EVE 005 V1.1.1 (2015-12) NFV; Ecosystem; Report on SDN Usage in NFV Architectural Framework
Open Data Center Alliance, Inc. (ODCA)	2013	ODCA Master Usage Model: Software-Defined Networking Rev. 1.0 © 2013 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.
Open Networking Foundation (ONF)	2013	Migration Tools and Metrics
	2013	Migration Use Cases and Methods (3 case studies: Google Inter-Datacenter WAN, NTT Provider Edge, and Stanford Campus Network)
Optical Internetworking Forum	2014	Global Transport SDN Prototype Demonstration

 

Additional materials may be available. See the Points of Contact article for links to websites of several open-source communities and standards development organizations.

 

1. Websites, SMB, and individuals.

Source	Date	Title
CIO.com, a subsidiary of IDG Enterprise	2015	CIOs Share Lessons Learned From the Journey to the Cloud
Shawn Ennis	2017	How Vendor Maturity Challenges NFV Adoption
Harvard Business Publishing	2015	Cloud Adoption Gets Serious: 2½ Years In
InformationWeek	2011	4 Lessons Learned From Virtualization Masters
Koybayashi, Seetharaman, et al	2013	Maturing of OpenFlow and Software-defined Networking through deployments
Latin School of Chicago	2010	Lessons Learned about Consolidation, Virtualization and Disaster Recovery
Levin, Canini, Schmid, et al	2013	Incremental SDN Deployment in Enterprise Networks (video available here)
Lin & Hart	2013	Seamless Interworking of SDN and IP
	2014	Seamless Interworking of SDN and IP
Mishra & Dasari	2014	GENI Deployment and Research at US Army Research Laboratory (NOTE: Registration required)
Sagar Nagare	2018	Evaluating Container Based VNF Deployment For Cloud Native NFV
Naqvi	2015	Technical and Non-Technical lessons learned from SDN Implementations
Packet Pushers	2015	Software Defined WAN – Night of Nerdery – Live From New York (podcast featuring Bloomberg, Gap, and Visa panel members)
		SDN: What Small and Mid-Sized Businesses Need to Know in 2015
Prayson Pate	2013-2021	A series of articles on LinkedIn i about aspects of NFV and SDN
Pepelnjak	2015	What NFV Means for Enterprise
SDxCentral	2016	4 Lessons the Telecom Industry Should Learn From the Enterprise
	on-going	SDN Webinars – a series of webinars on current industry deployments of SDN
University of Pittsburgh Medical Center	2014	SDN meets the real-world: implementation benefits and challenges (used by permission)

 

1. Training Resources.

Source	Date	Title
Acadia Technology Group	2018	11 Rules for Software-Defined Networking Integration
Donovan & Prabhu	2017	Building the Network of the Future: Getting Smarter, Faster, and More Flexible with a Software Centric Approach (book)
Goransson & Black	2014	Software Defined Networks: A Comprehensive Approach (book)
Matt Oswalt blog	2014-2015	SDN Protocols in 5 parts: Part 1: OpenFlow Basics Part 2: OpenFlow Deep-Dive Part 3: OVSDB Part 4: OpFlex and Declarative Networking Part 5: NETCONF
	2015	Open-Source Routing: QUAGGA, ExaBGP, and BIRD
Mininet – GitHub	2015	Introduction to Mininet
Mininet – SIGCOMM	2014	Tutorial: Teaching Computer Networking with Mininet
Nadeau & Gray	2013	SDN: Software Defined Networks. An Authoritative Review of Network Programmability Technologies (book)
NS-3 Network Simulator	on-going	Discrete event network simulator with OpenFlow 1.3 support
ONF	2014	Migration Use Cases and Methods (guidelines, methods and recommendations to migrate network services from a traditional network to SDN)
TechTarget.com	2015	Five SDN starter kit options you should know
	2015	SDN starter kits remove some do-it-yourself aspects of an SDN deployment
Tittel (Tom's IT Pro)	2017	Best Free Software Defined Networking (SDN) Training and Materials

 

1. Testing Resources.

Source	Date	Title
BISmark – Georgia Tech	2011	Managing the Home Network
BISmark – Project BISmark	2014	Project BISmark - Broadband Internet Service Benchmark
Canini, Enzano, et al	2012	A NICE Way to Test OpenFlow Applications
Hongyi	2014	Automatic Data Plane Testing
Kurshid, Zou, Zhou, et al	2013	VeriFlow: Verifying Network-Wide Invariants in Real Time
Microsoft	2022	Troubleshoot the Windows Server Software Defined Networking Stack
ONF	on-going	OpenFlow Conformance Certification
SDN Testing	2015	blog of various open-source and commercial SDN controller test results
University of New Hampshire InterOperability Laboratory (UNH-IOL)	ongoing	SDN Test Plans: Certification, Conformance, Interoperability
	ongoing	SDN and Routing Testing Services

 

Additional materials may be available from commercial testing service and equipment providers and open-source testing software developers on their respective websites. A partial list includes Accedian Networks, European Advanced Networking Test Center AG, Keysight Technologies, Paragon Active Assurance, Spirent Communications plc, UNH-IOL and Vivai Solutions, Inc.

Other listings of open-source testing software developers are available in the Points of Contact article, here and in Table 1 of this paper.

A collection of policy and guidance documents related to Software-Defined Networking (SDN) in 4 parts.

Part 1: United States (US) Federal government (other than the DoD) organizations documents

Part 2: US Department of Defense (DoD) organizations documents

Part 3: US Non-government and State and Local government organizations documents

Part 4: International organizations and organizations outside the United States (including Canadian, European, Asian, Australian and others) documents

(Note: A policy document is a document setting forth specific actions that must be taken or goals that must be achieved. A guidance document is a document recommending non-mandatory actions that could be taken or methods that could be used to achieve recommended goals. A best practices document describes actions or practices that are known to produce good outcomes when followed.)

---

Part 1: United States (US) Federal government (other than the DoD) organizations documents

Department of Homeland Security (DHS)

Cybersecurity & Infrastructure Security Agency (CISA) 

Edge vs. Core - An Increasingly Less Pronounced Distinction In 5G Networks, Dec, 2020

Multi-State Information Sharing & Analysis Center (MS-ISAC)

#StopRansomware Guide, May, 2023

National Security Telecommunications Advisory Committee (NSTAC)

NSTAC Report to the President on Software-Defined Networking, Aug, 2020

Federal Communications Commission (FCC)

Technological Advisory Council, Cybersecurity Working Group, Securing SDN/NFV Sub-Working Group

White Paper: Considerations for Securing SDN/NFV, Jan 2016
Security BCP Recommendations for SDN/NFV, Dec, 2016

National Security Agency (NSA)

Overview of Software Defined Networking (SDN) Risks, Feb, 2017
Managing Risk from Software Defined Network Controllers, Dec, 2023

National Institute for Standards and Technology (NIST)

Application Container Security Guide, Special Publication 800-190, Sept, 2017
Foundational Cybersecurity Activities for IoT Device Manufacturers, May, 2020
Software Defined Virtual Networks program, updated Sept, 2020

Office of Management and Budget (OMB)

Office of the Federal Chief Information Officer (OFCIO)

White Paper: Networks of the Future, Dec, 2019

Office of the President

National Science & Technology CouncilFoundational Cybersecurity Activities for IoT Device Manufacturers, May, 2020

Operationalizing Software-Defined Networks, Sep, 2018

---

Part 2: US Department of Defense (DoD) organizations documents

Defense Information Systems Agency (DISA)

DISA Software Defined Enterprise, Nov, 2017
SDN Controller Security Requirements Guide, Mar, 2020

Information Analysis Center (IAC)

Cybersecurity & Information Systems Information Analysis Center (CSIAC)

Software Defined Networking for Army’s Tactical Network: Promises, Challenges, and an Architectural Approach, Fall, 2018

Secretary of Defense

Defense Innovation Board

Fully Networked Command, Control, and Communications (FNC3) Recommendations, Oct, 2019

United States (U.S.) Army

Program Executive Office Command Control Communications-Tactical (PEO-C3T)

Software-defined networking could get the Army’s data moving faster, Dec, 2019

---

Part 3: US Non-government and State and Local government organizations documents

American Council for Technology-Industry Advisory Council (ACT-IAC)

Software Defined Networking and Network Function Virtualization, May, 2017

California

SB-327 Information privacy: connected devices, Sep, 2018

Microsoft

Troubleshoot the Windows Server Software Defined Networking Stack, Jun, 2022

---

Part 4: International organizations and organizations outside the United States (including Canadian, European, Asian, Australian and others) documents 

European Telecommunications Standards Institute (ETSI)

Industry Specification Group for Network Functions Virtualisation (ISG for NFV)

An extensive series of NFV Standards Reports are available here
An extensive series of Management and Network Orchestration (MANO) Standards Reports are available here
An extensive series of Multi-access Edge Computing (MEC) Standards Reports are available here
Ecosystem: Report on SDN Usage in NFV Architectural Framework, Dec, 2015

European Union Agency For Network And Information Security (ENISA)

Threat Landscape and Good Practice Guide For Software Defined Networks/5G, Jan, 2016
Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures, Nov, 2017

Groupe Spécial Mobile (GSM) Association (GSMA)

Considerations, Best Practices and Requirements for a Virtualised Mobile Network, May, 2017

Open Networking Foundation

Impact of SDN and NFV on OSS/BSS, Mar, 2016
SDN Migration Consideration and Use Cases, Nov, 2014
Software-Defined Networking: The New Norm for Networks, Apr, 2012

Topics in the Software-Defined Overview

1)    Introduction

a)    What is a Software-Defined Technology?

b)    What is the difference between a software architecture and an emerging architecture? 

c)    What is the difference between a standards development organization (SDO) and a software development organization (SWDO)?

d)    What is virtualization?

e)    Examples of the evolution of a concept’s virtualization

i)    Radio Access Network (RAN)

ii)    Network

iii)    Cloud Networking

f)    Where is the Edge in SDN?

2)     Software-Defined Networking Architecture

3)     Network Functions Virtualization Software Architecture

4)     Software-Defined Internet Exchange Point

5)     Software-Defined Security Architecture

6)     Network Virtualization Architectures

7)     IT Infrastructure Virtualization Architectures

a)     Software-Defined Data Center

b)     Software-Defined Workspace/Workplace

c)     Software-Defined Architecture

d)     Software-Defined Storage

e)     Software-Defined Data

 8)     Emerging Software-Defined Everything Architectures

 

1. Introduction

This Software-Defined Overview article begins with a discussion of several underlying concepts that are key to the development of some of the many software architectures and emerging architectures that are part of Software-Defined Networking (SDN) and other Software-Defined technologies.

a) What is a Software-Defined technology?

Consider any technology that involves both software and the virtualization of some physical computing, storage or networking/communications device(s). The nature and the name of that technology will change over time. For example, when the concept of a physical server was virtualized, the result might have been called a “Software-Defined Server” rather than a “virtual machine” but it was not to be (until years later).

A Software-Defined technology can also involve both software and the virtualization of data or programs apart from the physical device or devices on which the data is stored or on which the programs run. The article “What you need to know about Software-defined Technology?” provides an introduction to SDN, while the Internet Engineering Task Force (IETF) Request for Comments (RFC) 7426 Software-Defined Networking (SDN): Layers and Architecture Terminology provides a more detailed technical description. 

b) What is the difference between a software architecture and an emerging architecture?

As used in this Software-Defined Overview article, a software architecture is an architecture that has been recognized by and is being supported by at least one standards development organization (SDO). An emerging architecture is an architecture that is being developed by or is currently being supported by at least one software development organization (SWDO) but that has not (yet) been recognized by any SDO.

c) What is the difference between a standards development organization (SDO) and a software development organization (SWDO)?

The purpose of an SDO is to develop, publish and maintain standards within a defined scope of responsibility. An SWDO is like an SDO in many organizational aspects, but its purpose is quite different. An SWDO is an organization formed by one or more interested individuals, non-commercial organizations and commercial companies. One purpose of an SWDO is to develop, publish, maintain and possibly even promote the use of software (or devices and related software) within a defined scope of responsibility, and (for some SWDOs) another purpose is to function as an SDO for such software. An SWDO may have additional purposes that are not limited to software development, such as hardware development. The scope of any SDO or SWDO may be self-defined or their scope may be defined by a higher-level organization. There are many more SWDOs than there are SDOs.

d) What is Virtualization?

The architectural concept of virtualization is older than any of the software architectures or emerging architectures discussed in this Software-Defined Overview article. For further details, see this review of virtualization technology evolution. As this article on technology trends observes:

The trend of virtualization is one of the most powerful forces in technology.

Virtualization is an integral part of any Software-Defined technology. Virtualization can be used to implement some (typically, but not necessarily) hardware-based feature along with some software-based features of that technology solely in software. Virtualization can be used to create an abstraction layer in software that conceals implementation details of one part of the technology from other parts of that technology, or from whomever or whatever is using that technology. For example, early in the evolution of the Software-Defined Networking Architecture (topic 2 below), the control plane was an abstraction layer that concealed implementation details of the forwarding table residing in the data plane from the management plane.

During the last 60 years more and more physical infrastructure resources, both information technology (IT) and operational technology (OT), have been virtualized. Physical computing resources have been virtualized, including memory, processors, displays, sensors, entire servers and even entire networks. Many different types of physical storage resources have been virtualized, including tape and disk drives, channels, storage subsystems and entire storage systems. Physical communications/networking resources have been virtualized, including switches, routers, gateways, firewalls and entire networks. All communications/networking hardware (not just the active resources such as switches, routers and gateways, but also the interconnection resources) can be virtualized. Even data can be virtualized.

More recently, almost all layers of software resources have become virtualized resources, including processor instruction sets, subroutines, applications software, operating systems software, and virtual desktop infrastructure (VDI) software. Complete computing center environments or selected subsets of their components have even become virtualized resources. Multiple such virtualization activities by different SDOs and SWDOs are ongoing, with limited coordination across their individual efforts.

Once something has been virtualized, along with other virtualized resources it is typically:

• run under an operating system image on a virtual machine, in turn controlled by an overarching hypervisor (such as VirtualBox, Hyper-V, or VMware Workstation to name just a few); or
• run under an OS-level virtualization called a container (such as Docker, LXC, or the older LMCTFY to name just a few) or a collection of containers, in turn controlled by an overarching orchestrator (such as Kubernetes or Kubenet, Docker Engine or Docker Swarm, Microsoft System Center Orchestrator, Otomi Container Platform, Red Hat Openshift, or Apache Marathon), or else
• run under a traditional operating system.

(This article compares and contrasts the characteristics of virtual machines and containers. This article provides some security recommendations for virtual machines, while this article provides some security recommendations for containers.)

 

 

 

 

e) Examples of the evolution of a concept's virtualization

 

 

 

 

i. Radio Access Network (RAN) provides an example of the evolution over time of a concept's virtualization.

The original physical RAN was virtualized to (naturally) become a virtual RAN (vRAN). Several vRAN variations quickly appeared, including: a 5G RAN, a “Software-Defined RAN (SD-RAN)”, a “Cloud RAN (C-RAN)”, and then a RAN Edge.

And the list of RAN just keeps on growing, already including 2G vRAN (that’s right, 2G!), small cell RAN, 5G New Radio RAN (5G NR), 5G New Radio RAN Light (5G NR-Light, also known as 5G Reduced Capacity or 5G REDCAP), 5G Standalone RAN (5G SA), 6E RAN, 6G RAN, and 7G RAN with even more to come.

And the concept of a RAN will continue evolving, since the emergence of SDOs and SWDOs such as the Open RAN (O-RAN) Alliance, the Telecom Infra Project and the Next Generation Mobile Networks (NGMN) Alliance through the infusion of artificial intelligence (AI) technology with RAN technology (AI-RAN). The AI-RAN Alliance is actively developing standards and emerging architectures for Open RANs, with the support of lobbying groups like the Open RAN Policy Coalition, using disaggregated software (note that even the term “disaggregated” has many different meanings, as described in this article). This AI-RAN paper answers Frequently Asked Questions about AI-RAN.

Some O-RAN Standards have already been published. In 2022 the European Telecommunications Standards Institute (ETSI) and the O-RAN Alliance published a report on standardizing O-RAN planes.  In 2023 Vodaphone and NTT Docomo, Inc. published a report on streamlining the process of testing multi-vendor O-RAN products. In 2024 the Acceleration of Compatibility and Commercialization for Open RAN Deployments (ACCoRD) project established testing protocols for network performance, interoperability, security and research into new Open RAN testing methods.

In 2022 this article briefly described the architectural elements (hardware and software) of several RAN emerging architectures. In 2021 this article attempted to explain the differences among the various vRAN and Open RAN emerging architectures, while in 2023 this article described various Open RAN Use Cases. In 2021 this article described the RAN Intelligent Controller (RIC) software component of an Open RAN architecture that’s responsible for controlling and optimizing RAN functions.  

In a different direction, in 2021 another set of SDOs and SWDOs began evolving the Open RAN emerging architecture into a private RAN architecture.

 

 

 

ii. Network is another example of a concept’s virtualization over time. It is discussed in Network Functions Virtualization Software Architecture (topic 3 below).

 

 

 

iii. Cloud networking (sometimes called cloud-based networking) is a (more involved) example of the evolution of a concept's virtualization. Several cloud networking software architectures and emerging architectures based on cloud computing technology are mentioned in this Software-Defined Overview article. 

 

 

 

 

f) Where is the Edge in SDN?

The term “edge” or ‘Edge” is used in different contexts by multiple software-defined technologies that are part of SDN. As described in 2022 in this article and also in this article, and as shown by the various ways in which the term “Edge” is used in the body of this Software-Defined Overview article, there are many contexts where an “Edge” can appear in SDN. There is even a Software-Defined Edge (SDE).

2. Software-Defined Networking Architecture

While the adage timing is everything does not always hold true, it has been true during the evolution of the SDN architecture. While there have been previous efforts to change router and switch architectures, the SDN architecture effort has been the most successful. The SDN architecture as originally envisioned (circa 2007) included:

• A data plane: Hardware that receives and forwards IP packets, that could be physically separated from
• A control plane: Software in this abstraction layer monitors the forwarding tables residing in the data plane and propagates changes in routing policies to the forwarding tables, and
• A management plane: Software that maintains the routing policies.

This introduction of an intermediate control plane to propagate changes in the routing policies to multiple forwarding tables was a significant addition during the early evolution of the SDN architecture. The control plane provided the management plane with a single, cohesive abstraction of multiple (possibly dissimilar) forwarding tables in the data planes performing distributed IP packet handling. This enabled the centralized management plane to dynamically determine global network behavior from a single location by maintaining the global routing policies. The separation of mechanism (IP packet handling) from policy (routing policies) is a well-established design principle in computer science.

 

By 2012, the SDN architecture had evolved to include the following elements:

• A management plane that became part of the Application Layer: Software called Business/Network Applications control the behavior and performance of a network. One way that Applications do this is by using the services of modules to maintain the routing policies. An application does not offer any Application Program Interfaces (APIs) to other Applications or to modules. The functionality of Network Applications modules included in different SDN implementations varies widely. The functionality of Business Applications modules is determined by the customer.
• A control plane that became the Control Layer: Software called Network Service modules in this abstraction layer performs one or more services, providing one or more APIs, allowing modules in the Application or Control Layers to make use of said services and returning one or more results. Some of the services these modules perform include monitoring the forwarding tables residing in multiple networking devices, and propagating changes in routing policies to those forwarding tables. Even though the Network Service modules that make up a Control Layer are installed on one or more physically or virtually separate SDN controllers, the modules function as though they were installed in a common location.
• A data plane that became the Infrastructure Layer: Upon matching a conditional entry in a forwarding table for a received IP packet, a networking device performs one or more actions, possibly including forwarding the IP packet. The forwarding tables residing in each device are structured to meet that device’s specific requirements. A device may be either physical or virtual. A device manufactured by an original equipment manufacturer may be referred to as a white box. Prior to 2007, the operating system (O/S) for a device was usually provided by the manufacturer of the device. More recently, the O/S for an “open network” (also referred to as an “open networking”) device is sometimes provided by an SWDO rather than by the manufacturer.

The evolution of the SDN architecture did not cease in 2012. If anything, it accelerated! For example, in 2014 an extension to include support for the Internet of Things (IoT) was proposed (SDN Architecture for the Internet-of-Things (IoT)) by a Multinetwork INformation Architecture (MINA) research project. For additional details about the early evolution of the SDN architecture, see this 2014 review.

And this evolution will continue – see Emerging Software-Defined Everything Architectures (topic 8 below). As shown by the number of SDN open-source communities in the Points of Contact article, this continuing evolution can result in confusion when implementing SDN.

In the SDN architecture:

• The Control and Application Layers communicate by means of “Northbound APIs” (NBIs). RESTful and RESTCONF are some examples. This diagram shows an example of communications between the Control and Application Layers using the RESTful NBI. The Open Networking Foundation (ONF) initiated the OpenSourceSDN initiative in 2015 (this initiative is no longer active, but the website was archived in 2017). NBIs developed by that initiative are available on GitHub.
• The Control and Infrastructure Layers communicate by means of “Southbound APIs” (SBIs). OpenFlow, P4, or NETCONF are some examples.
• Data modeling languages like Yet Another Next Generation (YANG) can facilitate the use of NBIs and SBIs.
• For communications within the Infrastructure Layer (originally called the Data Plane), several APIs and API implementations have been standardized, including the OpenDataPlane (ODP) and the Data Plane Development Kit (DPDK).

Different SWDOs may use different terminology to describe the elements of their SDN architecture. A Layer in one may correspond to a Plane or a Tier in another, or not. For additional details about terms in the SDN architecture, refer to this glossary or this glossary. In the future, the scope of the SDN architecture could expand to include security – see Software-Defined Security Architecture (topic 5 below).

3. Network Functions Virtualization Software Architecture

The realization that physical network function components (PNFCs) (e.g., firewalls, load balancers or other network elements) could be virtualized was the foundation for the “Network Functions Virtualization (NFV)” software architecture developed by the ETSI Industry Specification Group for NFV (ISG for NFV) SDO. ETSI has also developed an NFV Open-Source MANagement (OSM) aligned with the ETSI NFV software architecture.

For further details, see this three part report from 2018 on the NFV software architecture:

Part 1: Foundations of NFV: NFV Infrastructure (NFVI) and VIM,
Part 2: Rising Roles of MANO, LSO, and Assurance, and
Part 3: State of the VNF Ecosystem.

Some industry observers worry that NFV promises too much too soon, as in this Does NFV Stand For Not Financially Viable? article, while others feel that the terminology describing the NFV software architecture is too complicated, as in this Lean NFV paper. 

 

An NFV software architecture includes the following elements:

• • “NFV Infrastructure (NFVI)”: An interconnected collection of IT infrastructure resources including virtual and physical computing devices, storage devices, networking devices, network functions and sensors. This collection need not be collocated. If the collection resides at more than one location (whether physical or virtual), the virtual and physical networking resources interconnecting those locations are included in the NFVI. The NFVI may even form an NFV cloud using something like NFV Openstack. It is neither assumed nor required that the NFVI uses Software-Defined technologies. In 2019 the Linux Foundation (The LF) (which was rebranded as the Mplify Alliance in Jun, 2025) and the Groupe Spécial Mobile (GSM) Association (GSMA) SWDO developed an NFVI reference architecture, called Botrange.
  • “Virtual/Virtualized Network Function (VNF)” or "Cloud-Native Network Function (CNF)": A collection of VNF Components (VNFCs) and PNFCs implementing an external network service delivery policy for an NFVI. The properties of each resource in the collection are specified in a VNF Descriptor (VNFD). A VNFD is a template that specifies the operational capabilities, deployment requirements and management characteristics of a VNFC or PNFC,
  • “NFV MANO” includes:
    1. NFV Orchestrator (NFVO): may configure and maintain an internal resource allocation policy, may configure and enforce a security policy, and may configure and maintain an external network service delivery policy along with the VNFDs for an NFVI. For example, when multiple NFVIs are running in physically or virtually separate containers, an NFVO can be used to manage them. What an Orchestrator is not is also important.
    2. VNF Manager(s) (VNFM): abstraction layer that instantiates, manages, and terminates VNFs or CNFs in accordance with an external network service delivery policy and VNFDs contained in the VNFs and CNFs of the NVFI.
    3. Virtualized Infrastructure Manger(s) (VIM): abstraction layer that manages the IT infrastructure resources of the NFVI in accordance with an internal resource allocation policy.
  • An “Operations Support Systems/Business Support Systems (OSS/BSS)” or “Lifecycle Service Orchestration (LSO)” element may also be included.

Approaches to controlling interconnected collections of IT infrastructure resources are proliferating. One approach is The LF Open Platform for NFV (OPNFV) Project. Another approach is The LF OPEN Compute Project (OCP). A survey of OCP initiatives is available here. Another approach is the emerging Software-Defined Cloud Interconnect (SDCI). A survey of SDCI implementations is available here. Yet another approach is the emerging Software-Defined Interconnect (SD-IX, sometimes called SDI) architecture. (Caution: Do not confuse the emerging SD-IX architecture sometimes called SDI with another emerging architecture also called an SDI mentioned in the Software-Defined Data Center (topic 7.a below).

SWDOs and researchers typically employ the use case methodology of systems analysis to identify and clarify implementation requirements and discuss anticipated benefits of specific cases of SDN architecture use or of NFV software architecture, as in the SDN and NFV use cases taxonomy and NFV use cases taxonomy articles. Some SWDOs and researchers may also apply the user story methodology.

For further details about terminology in the NFV software architecture, refer to the ETSI Group Specification NFV 003 Terminology for Main Concepts in NFV. In the future, the scope of the NFVI software architecture could expand to include security – see the Software-Defined Security Architecture (topic 5 below).

4. Software-Defined Internet Exchange Point

Another network function that can be virtualized is an “Internet Exchange Point (IXP)”. An IXP using SDN and possibly other emerging Software-Defined architectures is called a “Software-Defined IXP (or an SDX)” or an industrial-scale SDX (iSDX).

(Note: Do not confuse the emerging SDxI architecture that is the subject of the Emerging Software-Defined Everything Architectures (topic 8 below) with this IXP network function.)

 5. Software-Defined Security Architecture

“Software-Defined Security (SDSec)” is an emerging security architecture under consideration for adoption by SDOs and SWDOs, and implementation by various companies in various ways. In SDSec software and emerging architectures, centralized maintenance of security policies could be separated from distributed security policy execution, in a manner analogous with centralized maintenance of the routing policies to the distributed routing policy execution in the SDN architecture. Security policies could specify who can take an action, what actions can be taken and when, where actions may be initiated, and where actions may be executed. As envisioned by the Open Networking Foundation (ONF) in an SDN context, the scope of Applications could be expanded to include configuring and maintaining an external security policy, while Network Service modules could implement that security policy. As envisioned by ETSI in an NFV context, the scope of the Orchestrator in the NFV MANO element could be expanded to include configuring and maintaining an external security policy for an NFVI, while VNFs could implement that security policy. SDSec is also under consideration as an element of the SDx Infrastructure emerging architecture (topic 8 below). Yet another approach to implementing an SDSec architecture is with an Endpoint Protection Platform.

Alternative SDSec emerging architectures include Software-Defined Perimeter (SDP) and the more recent Zero Trust Network Access (ZTNA) (which is just one way of implementing Zero Trust Security and sometimes called the Zero Trust Security Model (ZTSM)). (This article summarizes how a Zero Trust SDSec architecture works, this article describes Zero Trust advantages and challenges, this article suggests best practices for transitioning from an older Virtual Private Network (VPN) security architecture to a ZTNA SDSec architecture,  while this article describes some Zero Trust use cases. Other SDSec emerging architectures include Software-Defined Protection, MicroSegmentation, Security Services Edge (SSE) and Secure Service Access (SSA). Several aspects of the SSE emerging architecture are explained in this article.

Meanwhile, other companies continue developing and marketing security products using phrases such as Security Information and Event Management (SIEM), Security Orchestration, Automation, and Response (SOAR), Endpoint Detection and Response (EDR), Extended Detection and Response (XDR), Open XDR, and Network Traffic Analysis (NTA). Several security product developers and providers have even joined together to form an XDR Alliance. This article cautions against common misperceptions of XDR and similar security products.

6. Network Virtualization Architectures

As part of the ongoing evolution of the NFV architecture, many “Network Virtualization (NV)” and "Enterprise Data Center Networking" software architectures and emerging architectures are appearing. Several examples of commercially available implementations are listed here.

They often include abstraction layers (such as overlay or underlay networks) that conceal (but do not change) the implementation details of the network resources from the network configuration, management or security software, offering hope that network automation may someday become a reality. Just which implementation details of the network resources are concealed, and the functions performed by the network configuration, management, or security software vary widely, depending on the specific software or emerging architecture. Some of the benefits, challenges and use cases of network virtualization are described in this article, along with examples of various network virtualization implementations. Several examples of commercially available implementations are available here.

The earlier Wide Area Network (WAN) routing technology MultiProtocol Label Switching (MPLS) continues to be widely deployed for the reasons given in this article, sometimes in conjunction with NV software and other “Software-Defined WAN (SD-WAN)” emerging architectures. This article explains why Internet Protocol version 6 (IPv6) matters for SD-WAN. This article describes the essentials for SD-WAN security. This article describes the SD-WAN service standards established in Apr, 2021, by the Metro Ethernet Forum (MEF) SDO (which was rebranded as the Mplify Alliance SDO in Jun, 2025). This article describes some of the pros and cons of both MPLS and SD-WAN.

SD-WAN is sometimes described as an “overlay-based SD-WAN” (or “tunnel-based SD-WAN”, in contrast to another emerging architecture, the “tunnel-free SD-WAN”). Other SD-WAN emerging architectures include "universal SD-WAN (uSD-WAN)", “open-source SD-WAN”, along with "Secure Access Service Edge (SASE)", an open-source SASE, and the Mplify SASE Service Framework (which are not to be confused with the SSE, SSA and other emerging SDSec). There is also an Mplify SASE Certification for Service Providers based on the ratings of its elements (such as SD-WAN, SSE, and ZTNA). This article explains why such certifications are so important. 

The key technologies enabling SASE are reviewed in this article and this article, and their differences are informative. This article compares the SD-WAN and SASE NV architectures, while this article explains how the two are so closely related that they can even be used together in conjunction with an SSE SDSec architecture. This article discusses how SASE can replace some older security technologies.

Some confusion is understandable since SASE and SSE are closely related, as this article explains, in contrast with other emerging NV architectures such as: “Flexible Service Edge (FSE)”, “Virtual WAN (VWAN)”, “Network-as-a-Service (NaaS)”, and “Intent Based Networking (IBN)” (which re-emerged as AI Networking, an example of the merger of AI and SDN). And, the impact of AI on networking will only keep growing, as discussed in this article published in 2023. The Mplify's NaaS Customer Experience white paper (registration required) reviews the evolution of the NaaS architecture.

Several open-source software implementations of SD-WAN architectures have emerged, and the Mplify SWDO has released an updated SD-WAN Services Standard 3.0 document, defining standard Edge, Controller and Orchestrator functions.

Implementations of virtual/virtualized “Evolved Packet Core (vEPC)” and virtual/virtualized “IP Multimedia Subsystem (vIMS)” WAN NV, together with network slicing and dynamic network slicing emerging architectures are offered by members of the “3rd Generation Partnership Project (3GPP)” (which has developed or is currently developing 3G-, 4G- and several 5G-Advanced long-term evolution (LTE) technologies, including LTE-MTC  (Machine Type Communication),  LTE Cat 1, LTE Cat1 bis, LTE M, Narrowband IoT (NB-IoT) and 5G REDCAP.  Additional early WAN NV emerging architectures are listed in this article.

SD-Branch NV emerging architectures are an expansion of the SD-WAN NV architecture as this article explains. Several SD-Branch use cases are discussed in this article, and several SD-Branch security tools and techniques are discussed in this article. SD-LAN emerging architectures are an alternative approach.

LAN NV architectural elements such as VNFCs and PNFCs may also be found in other emerging architectures such as the Software-Defined Data Center (topic 7.a below).

Independently of the ongoing evolution of the NFV architecture, virtualization is being implemented in a growing number of “Wireless LAN (WLAN)” emerging software architectures. Some examples include “Virtual LAN (VLAN)”, "Fixed-Wireless Access (FWA)", “Virtual eXtensive LAN (VXLAN)”, and “Network Virtualization using Generic Routing Encapsulation (NVGRE) LAN”.

Emerging architectures for both physical and virtual network fabrics and networking switch fabrics continue to evolve, as part of a quixotic quest for an SD-WAN that is an all-encompassing Fabric for Universal Networking (FUN). Seriously!

7. IT Infrastructure Virtualization Architecture

Abstraction layers can be introduced anywhere in an IT infrastructure. If an abstraction layer is introduced to conceal implementation details in an IT infrastructure from the customer interface to that IT infrastructure, it may result in a Software-Defined Data Center (topic 7.a below) or a Software-Defined Workspace (topic 7.b below). If an abstraction layer is introduced to conceal implementation details of some applications in an IT infrastructure from the customer interface to those applications, it may result in a Software-Defined Architecture (topic 7.c below). If an abstraction layer is introduced to conceal details of some storage resources in an IT infrastructure from the application interface to those storage resources, it may result in Software-Defined Storage (topic 7.d below). If an abstraction layer is introduced to conceal details about the attributes of data, or details about the storage resources of an IT infrastructure where data resides, from the applications that access that data, it may result in Software-Defined Data (topic 7.e below).

7.a. Software-Defined Data Center

The original concept of a data center consisted of one large collection of centralized servers. The concept is evolving into a continuum of multiple distributed cloud-based computing resources, from the macro to the local, seamlessly interconnected with end-to-end continuity, flexibility, scalability, reliability and security, as described at length in this Network the Cloud white paper.)

Various SWDOs are developing “Software-Defined Data Center (SDDC)” emerging architectures. Broadly speaking, an SDDC is a data center implemented using virtualization together with one or more Software-Defined software or emerging architectures built using a combination of one or more physical and/or virtual network architectures, and each SDDC emerging architecture has been given a name by their SWDO. The SDDC emerging architectures include Software-Defined Data Infrastructures (SDDIs), Software-Defined Infrastructures (SDIs), Software-Led Infrastructures (SLIs), and Platform-as-a-Service (PaaS) (among other names). (Caution: Do not confuse the emerging SDI architecture with another emerging architecture SD-IX sometimes called SDI mentioned in Network Functions Virtualization Software Architecture (topic 3 above).)

Since multi-cloud (also known as multicloud networking software, multicloud NAAS, or distributed cloud networking (DCN)) appeared in 2019 it has continued to evolve, by merging with other emerging network virtualization architectures (including edge computing, as described in this article). Multi-cloud using SD-WAN is an SDDC emerging architecture that combines an SD-WAN emerging network virtualization architecture (several were mentioned in the Network Virtualization Architectures (topic 6 above)) with cloud computing to create an SDDC. Cross-cloud interconnect is an SDDC emerging architecture that incorporates an abstraction layer enabling one or more applications to simultaneously execute across multiple clouds hosted by one (or possibly more) cloud service providers. Paraglider is The LF open source cross-cloud control plane project for configuring cloud networks.

An SDDC may include a combination of both physical and virtual resources: discrete, composable, converged or hyper-converged infrastructure (HCI). HCI resources may sometimes be described as being edge orchestrated. This article explores the differences between composable and HCI resources. A composable infrastructure can even be built with composable fabric, as described by this article. An SDDC may even include disaggregated HCI resources (the term “disaggregated” has several meanings, as described in this article).

The customer interface is often called “Infrastructure-as-a Service (IaaS)”. An SDDC is implemented using a combination of local IT infrastructure, fog computing, edge computing and a refinement of edge computing called multi-access edge computing (MEC, originally called mobile edge computing) resources, while fog computing is an expansion of MEC, as this article explains. In 2018 the ETSI ISG for MEC released an MEC standard.

For further details about fog computing versus edge computing, see this article. See this article for some edge computing use cases. The IoT can be used to solve challenges that arise when implementing edge computing, as described in this article, and conversely edge computing can be used to solve challenges that also arise when deploying IoT clusters, as also described by that same article. Their use together can also give rise to a need for edge security. An Open Edge Computing Initiative SWDO is also working to advance edge computing technology. An SDDC implemented using a combination of MEC and HCI could be even better. Just to be clear, edge computing and MEC are not the same thing, as this article explains, nor are distributed cloud and MEC, as this article explains. This Open Glossary of Edge Computing defines terms used when discussing edge computing. (Note: just to complicate matters, there are multiple definitions of “edge’ computing.)

According to this article, based on the IT resources included in an SDDC, an SDDC can be categorized as either:

1. 1. discrete, physical servers (bare metal) plus other physical IT resources,
   2. virtualized servers (running on hypervisors) plus physical IT resources,
   3. HCI (running on hypervisors), or
   4. HCI (running on hypervisors, while also adding containers to the mix of IT resources included and called an Application-Defined Infrastructure (ADI) by some SWDOs).

The ETSI ISG for MEC and ISG for NFV SDOs are working with the OpenFog Consortium (which, after merging with the Industrial Internet Consortium is now called the Industry IoT Consortium) to establish standardized APIs to enable deploying MEC resources in NFV infrastructures, as described by this article.

An abstraction layer is introduced to conceal various details (which vary with the SWDO) of the internal resource allocation policy and the intrinsic (possibly device-specific) orchestration, management, and provisioning characteristics of the resources in the SDDC.

Different SWDOs may use different terminology to describe their different SDDC emerging architectures. 

7.b Software-Defined Workspace/Workplace

“Software-Defined Workspace (SDW)” (also called Workspace-as-a-Service or an integrated workspace platform) is an emerging architecture. It can be difficult to differentiate from another emerging architecture, Software-Defined Workplace (also called Workplace-as-a-Service). These emerging architectures employ multiple abstraction layers in order to support the use of any type of application on any platform from anywhere via any network.

Different SWDOs may use different terminology when describing the elements of their emerging SDW architectures.

7.c Software-Defined Architecture

“Software-Defined Architecture (SDA)” is an emerging architecture in which an abstraction layer introduces outer APIs (NBIs) and inner APIs (SBIs) for selected applications. The NBIs conceal the implementation details of those applications and their run-time environment from external customers/users. The SBIs conceal these details from other applications. This makes it possible to transparently modify or replace the applications or their environment.

An SDA is a further evolution of the earlier “Service-Oriented Architecture (SOA)” software architecture, and the evolution keeps going on. An SDA is more recently being called a cloud-native architecture by SWDOs, and is used to develop cloud-native applications (often implemented as microservices housed in containers) to support cloud-native infrastructures. This article describes some cloud-native application use cases. Note that not every SOA application can be used to develop a cloud-native application for the reasons given in this article. Different SWDOs may use different terminology to describe the abstraction layer of their SDA emerging architecture.

7.d Software-Defined Storage

“Software-Defined Storage (SDS)” emerging architectures separate virtual and physical data storage resources from the software that manages those storage resources, in a manner similar to the separation of the data plane from the management plane in the early evolution of SDN architecture. This article compares and contrasts SDS emerging architectures with the earlier software architectures: Storage Area Networks (SAN) and Network-Attached Storage (NAS). Various SWDOs are developing SDS emerging architectures, such as this initiative by the Storage Networking Industry Association (SNIA) and the Virtual SAN (VSAN) offerings by Cisco Systems, Inc.

An SDS implementation is typically transparently modifiable while on-line and in-use. For example, without disrupting availability or performance, storage capacities can be increased or decreased, or individual storage resources can be repaired, upgraded or replaced.

This article argues that 5 key attributes must be part of any SDS software or emerging architecture. Different SWDOs may use different terminology to describe their SDS emerging architectures which do not always include all 5 attributes.

7.e Software-Defined Data

Could “Software-Defined Data (SDD)” become the next step in the evolution of SDS? Implementations of this emerging architecture by SWDOs, including DataSphere (ceased operation in 2018) and ViPR (originally developed by EMC Corp, now marketed by DELL Inc), are mentioned in this International Data Corporation Community article.

The SDD emerging architecture would use a combination of data virtualization and structural metadata to create an abstraction layer that separates data from some of its attributes. These data attributes can include format, storage media, access protocol (IPv4 or IPv6) and physical locality. In the SDD emerging architecture, data would be accessible at any time; appear to reside on any storage media; and appear to be accessible using any protocol, whatever the actual location of the data, the storage medium it resides on, the protocol used to access it, the intended use of that medium (such as on-line, archival or disaster recovery), or the format of the data on the storage resource where it resides (all of which could transparently and automatically be changed over time in response to data access patterns).

8. Emerging Software-Defined Everything Architectures

Since at least 2016, several Software-Defined Everything (SDx) architectures have been under development by different SDOs and SWDOs, with only limited coordination between their separate efforts. Some of these efforts are still ongoing.

In 2016 one SDx emerging architecture (originally called “Software-Defined Anything”) became the basis for an inclusive SDx Infrastructure (SDxI). For further details about this SDxI, refer to this series of articles:

Part 1: Definition of SDx
Part 2: Cloud Infrastructure
Part 3: SDx Infrastructure
Part 4: SDx Infrastructure Buyers
Part 5: SDx Use Cases
Part 6: Infrastructure
Part 7: Infrastructure Form Factors & Delivery Models
Part 8: Succeeding in an SDx World

written by SDxCentral, LLC (originally called SDNCentral, LLC). Network performance management (NPM) elements of the architecture are described in this article and application performance management (APM) elements of the architecture are described in this article. When the NPM and APM elements of an SDXI are converged, they may be referred to as a unified performance management (UPM) element as described in this article.

(Note: Do not confuse the SDX network function that is the subject of the Software-Defined Internet Exchange Point (topic 4 above) with the SDxI architecture.)