Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

SDN/NFV – Opening Doors to Next Generation Networking

DZone 's Guide to

SDN/NFV – Opening Doors to Next Generation Networking

Connected devices require complex network transformation to support desired scalability and programmability requirements.

· IoT Zone ·
Free Resource

The networking world is undergoing a radical transformation to support the diversified needs of emerging applications/services like IoT, AR/VR, V2X, etc. Communication service providers and telco vendors are expanding their portfolios with these user-centric services. The need to connect billions of devices, as well as the massive increase in the number of network nodes and enormous data generation/transmission over the network, can’t be supported over traditional networks. These new services require complex network transformation to support the desired agility, scalability and programmability requirements. They require designing, deploying, and managing network components via software programming. This is where Software-Defined Networking (SDN) and Network Function Virtualization (NFV) are getting embraced as key technologies to support these network transformations. SDN decouples the network control part from the forwarding functions thus enabling direct programmability of the network control. NFV, on the other hand, is the migration from physical networking h/w to virtualized network functions for specific network elements.

Push Towards NFV

Traditional networking paradigm suffered from several pain points – high capex, high operational costs, delayed time to market, complex upgrades, limited scalability, and resource over-provisioning to support high demands, etc. NFV addresses these pain points by offering on-demand service creation, on-demand resource allocations and reduced CAPEX/OPEX by offering vendor independence.

The initial architectural transition towards NFV was seen in terms of automation, provisioning, complete lifecycle management of virtual network functions, end-to-end service provisioning across a set of physical and virtual resources and conceptualizing multiple slices in the same hardware. Of lately, zero-touch provisioning (ZTP) and closed-loop workflow automation have been getting a lot of industry focus. Thus, most of the open-source NFV initiatives have been introducing projects around automated one-touch service and infrastructure provisioning, tools for operational visibility (telemetry), analytics, and resultant optimization to the network.

NFV initially focussed towards DC virtualization but gradually its usage got more diversified – from edge to core. Recent standardization efforts around 5G (3GPP) and Edge computing (ETSI) are heavily inclined on NFV – most of the core and edge components are expected to be virtualized and executed in the context of VMs or containers running on NFV infrastructures.

The Growth of SDN

Initial use case of SDN was oriented towards replacing the traditional routing/switching devices with white box switches — where the forwarding logic remained in the switches but the control part that dictates the routing/forwarding tables moved to a centralized controller (SDN controller). This paradigm has been extended to support other scenarios like implementing complex QoS policies, centralized device configuration, traffic management, load balancing, setting L2/L3 network fabric across elements, etc. These scenarios are realized as north-bound applications developed on the top of the SDN controllers. Operators can utilize the APIs offered by these applications to add the desired network programmability across the underlying switching fabric. SDN controllers convert the user-driven intent to protocol level messages as per the managed devices in the switching fabric.

To support multiple use cases, SDN controllers support an exhaustive list of southbound protocols like OpenFlow for switching of packets, NetConf, and SNMP for device configuration/management and routing protocols like BGP, ISIS, and OSPF to support integration with traditional routing fabric. gRPC, gNMI, and gNOI are some recent additions to the southbound interface of SDN controllers. These new protocols and recently introduced P4 programming language of SDN, are pushing the SDN technology towards pure white box switching where even the data plane pipeline can be completely programmed by the Operator. Open Networking Foundation (ONF) has come up with a project ‘Stratum’ that proposes a new control interface offering pipeline abstractions for various switching chips. This project extensively uses P4 programs to define tables, actions etc, thus offering completely programmable chips. While P4 is for switching logic, the new protocols gNMI and gNOI are for configuration/monitoring (OpenConfig over gNMI) and operations (gNOI).

The Role of the Open-Source Community

Both SDN and NFV initiatives are highly dominated by open-source software. NFV has influenced transformations at the RAN, edge or core of the network – using different modes of deployment – private clouds or hybrid clouds. Private cloud NFV infrastructures at these locations use different virtualization infrastructure managers (VIM) like OpenStack, OpenShift, OpenBaton, etc. OpenStack VIM is the most extensively used VIM in private cloud deployments. The OpenStack community has been focussing on adding new projects based on diverse requirements of networking. With applications moving to microservices-based architecture, supporting containers became mandatory. For edge deployments, supporting minimal footprint OpenStack images is mandatory. These kinds of unique requirements are catered by OpenStack using different projects.

Management and orchestration (MANO) of NFV deployments has been a prime focus of the open-source community. Two popular MANO frameworks picking up pace in the industry are ONAP (owned by Linux Foundation) and OSM (owned by ETSI). Each of these tools allows deployments of network services, defining workflows, monitoring and closed-loop automation for resource optimization.

The open-source community is also coming up with interesting initiatives like ‘StarlingX’ and ‘Airship’ to ease out the NFV deployment challenges. ‘StarlingX’ offers ISOs which can be directly deployed to setting up an OpenStack-based cloud on the edge. ‘Airship’ offers complete lifecycle management of the OpenStack cloud, both at edge and core. These projects are generally supported by big telecom operators and have huge acceptability in the market.

On the SDN front, the two most popular open-source projects are OpenDaylight and ONOS. Both of these projects have strong protocol support at the southbound side, thus managing a diverse set of devices. These projects have also been integrated with VIMs like OpenStack to realize network slicing and service function chaining use-cases. These SDN controllers provide northbound abstractions for configuration and management as well.

Revenue Opportunities in SDN/NFV

As per market surveys, the SDN global market is distributed across multiple use cases now. Service function chaining, network slicing, SD-WAN, Central Office re-architected as data center (CORD), NaaS/BoD, etc. are some latest additions to this market. Lots of opportunities around northbound application development and southbound protocol extensions will be seen in the near future.

The NFV market is very well defined — almost all components of the network are moving towards virtualization. VNFs are supported in each of the following categories — switching and routing (virtual load balance, vSwitch, vRouter), Core WAN functions (virtual IMS, virtual PCRF, virtual EPC, virtual RAN), standard devices (virtual FW, virtual DNS), etc. While the translation to virtualized implementations will be done in-house, the management and orchestration part of these virtualized deployments will open up a huge market for vendors. 

Topics:
network architecture ,virtual network function

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}