Showing posts with label NFV. Show all posts
Showing posts with label NFV. Show all posts

Wednesday, January 25, 2017

Network Abstraction Virtualization SDN VNF

Recent question asked:  What is this network virtualization stuff I keep hearing about?


a representation of packets in a tunnel
Figure 1.  Network packets and trains


Network virtualization can apply to multiple areas of networking.  At a high level....

Network Virtualization technically started with VLAN, which stands for virtual LAN, where the broadcast domain was abstracted away from ALL of the physical endpoints in the network.   This made it possible to group computers on a network with some level of logic, it's done in software rather than by changing wires and can be considered an abstraction of the wiring.

There are a couple of different types of Software Defined Networking (SDN), the leading one right now is an "overlay"  in a tunnel over an "underlay" or "provider" network.  It exists as an abstraction of one network on top of another, where the underlay is responsible for fast packet performance (traditional networking) and the overlay is responsible for specific awareness or intelligence of the communicating endpoints.
     The simple example:  If you consider a train the "underlay" network (it moves packets efficiently) then a person riding on the train with their own bag is the "overlay."  The train doesn't have to know where the person is going, just that a portion of their travel is between these two endpoints.  This abstracts the path of the data packets from the logic of how they are connected by placing the traffic in a network tunnel.  Common tunnel types are VxLAN, GRE and NVGRE.  This type is associated with technology like VMware NSX and Microsoft Hyper-V networking.

   There is another SDN type that acts on the flow of packets between their source and destination. This also abstracts the path of the data packets from the logic of how they are connected, but in difference to the concept above, this type of SDN acts on the forwarding plane of network hardware primarily.  This type is associated with technology like OpenFlow.

And there is also another type of network virtualization happening right now, where the "function" or software coding of a network device is built within a software package, like a virtual host or container, that can be run on a standard server.  This is called a Virtual Network Function (VNF) and is closely associated with the advocacy of moving from  hardware to software delivery of services, often called Network Function Virtualization (NFV).
     The simple example:  A router has been historically a device with interfaces that moves packets from one physical or logical interface to another according to a configured pattern.  A VNF router is software (not a device) that runs on a server that moves packets from one software or logical interface to another.  This abstracts away the hardware in favor of software delivery of the capability.  There's a bit of this in the enterprise and a lot starting in the Telecommunications Carrier space.

Again, this is at a high level and hope that it helps.  There are other network abstractions currently in use, but these are the primary ones getting all of the media attention today.

Friday, January 20, 2017

Modern Network Areas in Software Defined

Software Defined LAN (SD-LAN, SDN) - Local Area Networking deployed as software combined with hardware and/or software as an overlay network (or possibly integrated) with exposed APIs that can be managed from a network controller or by direct programmatic integration.

Traditional Networking Model
Figure 1.  Traditional Network Model
Software Defined Networking Model
Figure 2.  Software Defined Network Model

Software Defined WAN (SD-WAN, SDN) - Wide Area Networking deployed as an appliance or VNF on a hypervisor, typically on a standardized hardware platform with exposed APIs that can be managed from a network controller or by direct programmatic integration.

Classical Network vs Software Defined WAN
Figure 3.  Classical vs Software Defined WAN

     Network Ecosystem - a WAN system created to provide integration capability between consumers and vendors in high population locations, like within a Data Center or between Data Centers within their service coverage area.  Examples in the industry:  Equinix, Telx.

     Universal Cross Connect - a WAN system created to provide integration capability between consumers and vendors that provides a connecting service by extending this service to specific customer locations via Telecom, Dark Fiber, etc. http://www.abusedbits.com/2015/09/hybrid-cloud-how-it-can-look.html

     Service Management Platform (SMP) – Software, tools, services that create the connections for customers between orchestrated networks and Hybrid Cloud. http://www.abusedbits.com/2015/09/hybrid-cloud-how-it-can-look.html

     Enhanced Cloud WAN Service - a WAN service were the routing, switching, firewall, proxy, as well as Internet and other capabilities are run within a Telecom Cloud and connectivity to the consumer is via any physical  means available, typically with a reduced equipment requirement at the customer premises. http://www.abusedbits.com/2016/10/wan-ecosystems-evolution.html

Virtual Network Function (VNF) - Any network capability implemented as an appliance or virtual machine and executed as software within a virtualization platform or framework, typically in an x86 hypervisor allowing specific access capability to the network interfaces.

Virtual Network Function VNF
Figure 4.  Virtual Network Function


Network Function Virtualization (NFV) - Management and control of virtualized network functions (VNF) that includes the OSS/BSS and management tasks for the lifecycle of VNFs.

     Management and Orchestration (MANO) - Platform RE:NFV-MANO - providing the roles of OSS/BSS as part of a related control framework inclusive of orchestration of network functions (Network Function Virtualization Orchestration - NFVO), management of VNFs (Virtual Network Function Manager - VNFM) and awareness of infrastructure management (Virtualzed Infrastructure Manager - VIM).  http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf 


Wednesday, October 26, 2016

NFV - Service Consumption

As the telecommunications industry starts delivering on Network Function Virtualization (NFV) via delivery of Virtual Network Functions (VNF) there should be a consideration for the service consumption mechanism that is driving this industry.

Consider that startup players in the market are approaching this market segment from enabling developers to directly integrate with their systems.  As the network ecosystems have evolved to include demand based services, these new players are providing the means to directly consume services that have been historically managed services.

There is a direct parallel of this model with the likes of Amazon Web Services and Microsoft Azure.  They have build a platform and enhanced it over time to directly address the service consumption model.  As a demand based service, compute and storage have largely been commoditized, or in the vernacular of the Value Chain, they are utility services.  You pay for what you use.

Telecommunications carriers need to be aware of the conditions this placed on the entirety of the IT market.  It shifted major capabilities to Hybrid Cloud and may further shift the entirety of workload execution to this demand based service area before the next major scale out.

During this evolution, traditional managed services may not survive in their current state.  Further, the directional of OSS and BSS have almost always been northbound.  As the digital shift continues, these functions need to be both North and Southbound.

Finally, there cannot be enough emphasis on this, this is technology segregated by logic.  Policy Enforcement that is well understood and tied together from MANO Service Chaining to VIM and finally to the consumer needs to be a foundational part of the plan of service delivery, enabled and enacted upon by API and made available to the masses that will be in a position to consume it.

The evolution of this space is ripe for a lambda function like execution in its maturity.

Tuesday, October 11, 2016

WAN Ecosystems - Evolution

Looking forward to the day of enterprise SDN and NFV for WAN service delivery.

This graphic is how I'm depicting the evolution underway:

WAN Ecosystems


Area 1:  Move toward Virtual Network Function, where individual devices are replaced by virtual network functions on as close to commodity x86 servers as possible.  This is a very pragmatic change that is already underway, with major companies like AT&T and their Universal CPE.

It will allow the edge to evolve in software timescales rather than hardware timescales.  It also makes practical large scale deployment at fixed monthly costs.

Area 2:  Deliver Ethernet to the edge and run the Virtual Network Functions, along with Enhanced Cloud WAN Services from within the Carrier estate.

Area 2 may have dependencies on local capability requirements, like application acceleration.

Consuming services from the Enhanced Cloud WAN area could provide rapid evolution, in software, of things like security perimeter enhancements as well as more options in routing traffic.

Area 3:  My personal favorite area.  Deliver any connection to any service within the ecosystem, on demand.  Programatically.

The delay between want and ready reduced from weeks to minutes if you are already attached to the ecosystem.

Make everything catalog based, so the order to fulfillment time for pre-existing customers is under their control.

Eliminate "stickiness" wherever possible.

There are some maturing vendors in this space and hopefully adoption will pull standardization along with it.


Friday, September 23, 2016

Network Function Virtualization - Value Chain 2016



Value Chain for NFV in 2016
I'm using this to describe the relative position of functions in the value chain for Network Function Virtualization (NFV).

Where the customer is consuming Virtual Network Functions (VNFs) there are a large number of supporting functions underlying the delivery of the VNFs.

This is intended to show the relationship between those elements that would perform part of a MANO Functional Block in the VIM (Virtualized Infrastructure Manager). #mapping