Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.

What is Network Functions Virtualization?

Oct 30th, 2015 2:23pm by
Featued image for: What is Network Functions Virtualization?
Feature image via Unsplash.
Editor’s Note: This article is first of a multi-part series exploring open source network virtualization. In this initial installment, Sridhar Rao explores the concept of Network Functions Virtualization (NFV).

When it comes to networking equipment, the traditional proprietary appliances are growing too diverse, making the operation of service additions and upgrades increasingly difficult for carriers and data center operators. Network Functions Virtualization (NFV) is an initiative of the ETSI Industry Specification Group (ISG) to simplify operations by virtualizing network functions previously performed by proprietary hardware.

NFV consolidates network functions onto industry-standard servers, switches and storage hardware. Offering an optimized data plane under virtualization, NFV allows administrators to replace traditional physical network devices with software running on commodity servers, reducing cost, power consumption and complexity.

Today’s networks are largely run by middleboxes, stateful systems supporting narrow specialized network functions (e.g., layer 4 to 7) and based on purpose-built hardware (typically closed and expensive). Not only do middleboxes contribute to “network ossification,” but also they represent a significant part of the network capital and operational expenses, due to the management effort that they require.

Using NFV can reduce or even remove the number of middleboxes deployed in current networks. It allows a single physical platform to be used for different applications, users and tenants through multi-versioning and multi-tenancy of network functions.

NFV also enables new ways to implement resilience, service assurance, test and diagnostics and security surveillance. It facilitates innovation towards new network functions and services that are only practical in a pure software network environment. NFV is applicable to any data plane and control plane functions, for either fixed or mobile networks, and also suitable for the automation of management and configuration of functions needed to achieve scalability.

Here are some of the network functions that could be virtualized through NFV:

  • Switching elements
  • Mobile network nodes
  • Home router operations
  • Set top box operations
  • Tunneling gateway elements
  • Traffic analysis
  • Service assurance
  • SLA monitoring
  • Test and diagnostics
  • NGN signaling
  • Converged and network-wide functions
  • Application-level optimization
  • Security functions

One potentially powerful use for NFV is in service function chaining, the process of dynamically chaining virtual network functions, such as router, firewall, DPI, and NAT into one integrated deployment. This process could be key to the application provisioning process.

As an example for service providers, a service chain may consist of an edge-router at the customer premises, followed by a firewall, a deep-packet inspection process and the NAT process, before reaching the provider-edge router. From the application perspective, an email service chain would include virus, spam and phishing detection and could be routed through connections that do not offer either delay or jitter guarantees.

In majority of the traditional networks, as each service required separate hardware, and building a service chain to support a new application required to acquire the network devices and cabling them together in the required sequence, which always proved cumbersome and error-prone.

However, moving network functions into software running on commodity servers can overcome these challenges. With NFV, one can have a centralized management and automatic configuration of resources and network. In addition, virtualization of network functions also provides the ability for dynamic service chaining, resource allocation, and scale-in or scale-out. This would naturally result in simplified network structure and shortened service-deployment time.

To be sure, the use of NFV also poses some challenges, chief among them is to carrier grade requirements for performance. Carriers typically expect uptimes of 99.999 percent for the services and 99.99999 percent for the infrastructure, including networking, much more demanding than the 99.9 percent expected from enterprise software. This is where NFV shines though, given that it was designed for carrier grade and service agility.

Ultimately, NFV aims to transform the way network operators architect and operate their networks.


When it comes to network virtualization, most would think of software-defined networking (SDN). NFV is separate from SDN. Both technologies are designed to increase flexibility, decrease costs, support scalability, and speedup the introduction of newer services. But you can run one without the other.


The ways in which SDN supports NFV

However, NFV is a complementary initiative to SDN, and SDN makes using NFV much easier and better, by improving performance, providing flexibility and simplifying operations. In particular, using SDN to support NFV can help with traffic steering (offload, bypass, selection etc.), dynamic scale-up and scale-out, multi-tenancy and load balancing.

SDN also helps NFV address tasks such as policy-managed forwarding and dynamic service orchestration. In turn, the use of dynamic virtual overlays and need for multi-tenancy in NFV also drives the need for SDN.

NFV in Action

Two use cases for NFV are for building out virtual customer premise equipment (vCPE) and for packet switching LTE mobile networks.

When virtualizing the customer premise equipment, the main idea is to move higher layer functionalities move from the box in the customer’s home (i.e. the home gateway) out to the network, where they can be handled by a commodity server.  Following this, the home gateway just becomes a simple L2 bridge, with many of the existing functionalities being virtualized.

With vCPE it would be possible to dynamically deliver any network functions, reduce initial and maintenance cost, and provide agile system reconfigurations. NEC used this approach with its own home gateway equipment to virtualize IP functions for subscriber and service management, virtualized network address translation, and DHCP services.

NFV also plays a crucial role in Evolved Packet Core (EPC), a chief component of the core network architecture for 3GPP‘s LTE wireless communication standard. The EPC includes Mobility Management Entity, Serving Gateway and Packet Data Network Gateway as sub-components.

There are numerous vendors of vEPC solutions in the market. OpenEPC (Open Evolved Packet Core), offered by Core Network Dynamics,  is a software implementation of a set of standard EPC components developed in C. Incorporating the main functionalities of 3GPP’s Evolved Packet Core (Release 9), OpenEPC can be deployed on standard commercial off-the-shelf hardware running Linux. OpenEPC includes core network mobility management, policy and charging control, client mobility management, subscription management, interconnection with access networks, and interconnection with applications and services.

NFV Architecture

The main blocks of the NFV framework are:

  • Infrastructure consisting of hardware resources and corresponding virtualization.
  • Management and Orchestration (MANO), consisting of orchestrator, virtualized network functions manager (VNFM) and Virtualized Infrastructure Manager (VIM).
  • Virtualized network function and corresponding element management systems (EMS).
  • Operations Support Systems and Business Support Systems (OSS/BSS).

The Architectural Framework proposed by ETSI NFV ISG. The grey lines show the main reference points, where green lines and blue lines show the execution and other reference points, respectively.

A Virtualized Network Function (VNF) is a Network Function capable of running on an NFV Infrastructure (NFVI) and being orchestrated by a NFV Orchestrator (NFVO) and VNF Manager. VNF is expected to support well-defined interfaces to other NFs, the VNF Manager, its EMS, and the NFVI, in addition to the well-defined functional behavior.

The NFVI is the totality of the hardware and software components which build up the environment in which VNFs are deployed. The NFVI provides a multi-tenant infrastructure leveraging standard IT virtualization technology that may support multiple use cases and fields of application simultaneously. NFV decouples software implementations of Network Functions from the compute, storage, and networking resources through a virtualization layer. This decoupling requires a new set of management and orchestration functions and creates new dependencies between them, thus requiring interoperable standardized interfaces, common information models and the mapping of such information models to data models.

The combination of NFVO, VIM and VNF managers is typically referred as MANO. NFVO is responsible for initialization and setup of new network services, network service lifecycle management, global resource management, validation and authorization of requests for NFVI, as well as policy management for NS instances.

The VNF managers are responsible for lifecycle management of VNF instances and the overall coordination between NFVI and the EMSs. Finally, the responsibility of VIMs, such as OpenStack, is well understood in the community – i.e., controlling, managing and monitoring the NFVI compute, storage and network resources.

Newer business models, varying subscriber needs and factors such as big data, personalization and virtualization have had a great impact on OSS/BSS systems over the past few years. There has been significant work on evolving these systems. In the NFV framework, OSS/BSS systems will mainly interact with NFVO for network service management, and over time OSS/BSS systems may end up managing more and more entities with the introduction of virtualization.

Functional Block of NFV Architecture


VNFs OpenIMS, Quagga, OpenNaaS-vCPE, OpenBTS, nwEPC, etc.
NFV Infrastructure 1. OpenDaylight , ONOS, ONF, OpenContrail, etc.
2. KVM, XEN, LXC, Bhyve, DPDK (Intel), Open Dataplane ( Linaro), OpenVZ, User-Mode Linux (UML), Bochs, Linux-Vserver, Virtual Box, ProxMox, OpenNode, Dockers.
3. Open Hardware Designs by Intel, Mellanox etc.
4. OpenVSwitch, GlusterFS, Libvirt, OpenStack, ManageIQ, OpenDaylight, AMQP/QPID, DPDK.
5. Switch Abstraction Interface.
MANO OpenMano, VIMs like OpenStack, CloudStack, Eucalyptus, Nimbus, OpenNebula, Open Virtualization Alliance, Reservoir, etc., and tools like Foreman and Cloudforms.
EMSs OpenNMS; some open source VNFs may also include EMS functionalities.
OSS/BSS OpenNMS, OSS/J, OSSBeans, Drools and JPBM.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.