Network Slicing - Flex Algo

GSMA defines, "5G networks, in combination with network slicing, permit business customers to enjoy connectivity and data processing tailored to the specific business requirements that adhere to a Service Level Agreement (SLA) agreed with the mobile operator. The customisable network capabilities include data speed, quality, latency, reliability, security, and services."

What is customisable network? Every network is fixed network like monolithic and fully dependent on the underneath resource availability. Fixed or monolithic sort of networks can only provide the connectivity with basic business SLAs. But 5G has different network requirements to support different type of business use cases like enhanced mobile broadband, massive machine to machine and ultra reliable low latency. To support different type of use cases, we need network which is like cloud native, we need network like micro-services, we need network like docker. To have these different customization we have to slice the network into different logical layers and use cases can be mapped to logical layers as per the signed business SLA. Dividing monolithic network into different layers or slices by using segment routing along with flexible algorithm is called customisable network or "Network Slicing".

What is Network Slicing?
Network slicing is an end-to-end concept that divides the physical network into logical parallel layers. It enables deployment of multiple logical, self-contained and independent shared or partitioned networks concurrently on a common infrastructure by abstracting, isolating and orcestrating it.

How do we create slicing in service provider network?
We can use flexible algorithm along with Segment Routing to create different slices in the network.

What is Flex Algrithm?
Segment Routing Control Plane - ISIS post explains about the Router Capability TLV (242). Router capability TLV has SR-Algorithm(Segment Routing Algorithm, Flex Algo, Flex Algorithm) Sub-TLV – This is type 19 sub-TLV. SR-Algorithm sub-TLV is optional. A router receiving multiple SR-Algorithm sub-TLVs from the same originator should select the first advertisement in the lowest-numbered LSP. This sub-TLV is used to calculate reachability to other nodes or to prefixes attached to the nodes. It has 2 values 0 and 1.

0: Shortest Path First (SPF) algorithm based on link metric. This is the well-known shortest path algorithm as computed by the IS-IS process. Consistent with the deployed practice for link-state protocols, algorithm 0 permits any node to overwrite the SPF path with a different path based on local policy.

1: Strict Shortest Path First (SPF) algorithm based on link metric. The algorithm is identical to algorithm 0 but algorithm 1 requires that all nodes along the path will honor the SPF routing decision. Local policy MUST NOT alter thevforwarding decision computed by algorithm 1 at the node claiming to support algorithm.

Flexible Algo means that this is flexible rather than fixed and the algorithm is defined by the operator based on per deployment basis.

Below are the steps used to discover and deploy Flex-Algo Topology:
Topology Discovery
1. A node computes Flex-Algo(K) if it is enabled for K. K is nothing but mathematical value starts from 128 till 255.
2. Flex Algo Topology is defined by pruning any nodes and links that is not advertising participation to K.
3. Advertises prefix-sid for that flex also node.
Compute Shortest Path
1. Compute shortest-path tree on Flex-Algo Topo(K) with the metric defined by K. Metric could be IGP, TE or Delay.

Build FIB Table
1. Install any reachable Prefix-SID of Flex-Algo(K) in the forwarding table

By using the above steps, let's see how Flex Algo(K) builds its topology. As per above figure, Node 10 supports 0,128 and 138. Node 1,2,3 and 4 supports flex algo 0 and 128. Nodes 5,6,7 and 8 supports flex algo 0 and 138. Node 9 supports flex also 0,128 and 138.

Node10 will be advertising prefix sid 16010 for flex algo 0, 17010 for flex also 128 and 18010 for flex algo 138. Similarly Nodes 1 will be advertising 16001 for flex algo 0 and 17001 for flex also 128.

By using the flex algo or flexible algorithm we can easily create network slices. Nodes below to same flex algo be part of same network slice. Once we create the slice, accordingly we can apply route the traffic on to the slices as per the business SLA.

Stay tuned for my next post, which will be discussing how to implement network slice on Cisco IOS-XR based platform. References
Click Here To Read Rest Of The Post...

CUPS: Control User Plane Separation

Telco’s user data traffic is getting doubled every year due to the proliferation of OTT video, social media, gaming and use of smart devices. This exponential growth in the mobile traffic has led lot of architectural changes which are aligned to SDN and NFV technology. At the same time OTTs are taking advantage because Telco’s are building network and serving 70% of OTT traffic only. At the same time, there is strong demand of serving OTT traffic with low latency, high throughput and best customer experience.

To serve all these requirements, Telco’s has to penetrate deeper and deeper in the region and create more EPC locations which means number of new users are not increasing as compare to the traffic demands.

Below is the current network architecture of LTE

During the launch of LTE, this was the best in breed architecture but as the traffic demands grow the intermediator or inline nodes are becoming bottle neck and creating head of Line blocking. CUPS - Control Plane User Plane Separation solves the issue and gave a new architecture approach which is easy to implement and leverages the SDN and NFV technologies so that all the SLA’s and KPI’s can be met.

In nutshell, CUPS allows for:
1. Reducing latency on applications and OTT/Video traffic.
2. Leveraging SDN to deliver Data Plane more efficiently and better scaling in Control Plane.
3. Supporting Increase of Data Traffic, by enabling to add user plane nodes without changing the number of SGW-C, PGW-C and TDF-C in the network.

Click Here To Read Rest Of The Post...

Network Slicing in 5G

Network slicing is a kind of virtual network architecture, which leverages the principles behind network functions virtualization (NFV) and software-defined networking (SDN). Network slicing allows telecom operators to slice a physical network into multiple virtual networks. From a mobile operator’s point of view, a network slice is an independent end-to-end logical network that runs on a shared physical infrastructure, capable of providing a negotiated service quality. The technology enabling network slicing is transparent to business customers. The virtual networks are then tailored to meet the needs of specific applications and services.

SDN and NFV will play vital role in network slicing. NFV provides the network functions like routing, firewall, load balancer etc. disaggregate from the dedicated OEM appliance and can be host on COTS hardware. The OEM dependency on supplying hardware, elasticity and faster time to market is the key to leverage NFV. SDN on the other hand is use to manage the network flows from the centralized controller sitting in data centers. The main role of the SDN is to provide on demand services without any kind of manual intervention.

5G is all about of providing connectivity to massive IOT devices (Industrial Slice or IOT Slicing), enhance Mobile Broadband for AI, ML and handling Video Traffic (Smartphone Slice) and providing access to low latency devices like Cars (Autonomous Driving Slice). Network Slicing can be achieved by using flex algo along with segment routing.

Network slicing will heavily be used in 5G networks to permit business customers to enjoy seamless connectivity and data processing tailored to the specific business requirements that adhere to a Service Level Agreement (SLA) agreed with the mobile operator. The customizable network capabilities include data speed, quality, latency, reliability, security, and services.

Click Here To Read Rest Of The Post...

How To Start With Python For SDN?

Recent post of "Which programming language should I Start Learning for Automation” and “Do I need to be programmer before learning Automation, SDN and NFV technologies” gave a clear approach to start with Python Language. Let me tell you one more time “Why Python Is Selected For SDN”.

1. Being platform independent and huge community support
2. It’s an easy language to learn
3. Great Online Documentation Available
4. Open Source With Easy Readable code
5. Code can be easily grouped in modules and packages
6. Easy API Integration
7. Finally it’s object oriented programming (OOPs)

Python is not only selected for SDN but it is widely opted by others communities also:

1. Software Testing
2. Web Development
3. Writing Network Applications
4. Scientific Applications
5. Scripting

Where to Start With Python?
Download Python 2.7 and start working on it. PIP (package manager/installer program)

What you should know before starting Python?
Before starting your python journey, please read more about PIP. PIP is (package manager/installer program). pip stand for "Pip Installs Packages" or "Pip Installs Python". pip is a package management system used to find, install and manage Python packages. Many packages can be found in the Python Package Index (PyPI). This is a repository for Python.

There are currently 89000 packages online and can be easily accessed by using https://pypi.python.org/pypi. You can use pip to find packages in Python Package Index (PyPI) and to install them. How to Start With Python? Download Python 2.7 and start working on it.
Click Here To Read Rest Of The Post...

Which programming language should I Start Learning for Automation?

Do I need to be programmer before learning Automation, SDN and NFV technologies: Gave a clear picture that you don’t need to be a programmer to learn these technologies? But knowledge of any basic scripting or programming language is always beneficial for carrier growth. Now the question arises which programming language to select out of the following:-

1. Python
2. XML
3. JSON
4. C/C++
5. Visual Basic
6. Perl
7. TCL
8. Ruby On Rails

Before the selection of any language we should understand that what the common among the languages are. As per my understanding, logic will remain be the same while implementing any of the languages. Secondly, all the languages have common understanding of defining variables, strings, functions, classes, inheritance, conditional statements, for and do-while loops, dictionaries, sockets, importing modules, file opening, error and exception handling. So it would be better if we first select any language and get the understanding of the basics functions. Once it is done, after that it would be very easy to become master in any of the language from understanding perspective. (Please mind that we are network engineers not programmers. The intent is to learn and understand the different puzzles with various buzz words and not to become master). Let the programming masters do their jobs. We will be helping them by extending the support.

Which programming language to select first and why?
I started my journey with C, C++, Visual Basic and Networking. After over period of time I can clearly differentiate among the languages. C is the mother or father of every language. During its writing time, it was designed to be very light. C++ was successor of C. It came with a concept of objects oriented programming. The basic problem with both the languages are platform dependent. That would be the reason it was used to build as base of other programming languages but never ever gain popularity over the web.

Java is widely opted because of its platform independent feature but it has lot of problems at server side. It was mainly a server side language rather than client side.

Python gained popularity in the last few years because of platform independent. Secondly it is very light in weight and have interactive shell too which most of the languages don’t have. It’s an easy to learn language and heavily adopted by every field. It has almost 88000 libraries available which can be used freely by anyone. Now even the lighter python version are also available which are called as PyEz (Python Easy). PyEz makes the code shorter by almost 85%. I have posted My First Step towards Automation: Controlling Junos with Python & PyEZ. Let’s understand how does it works with the help of an example.

A raw python script uses the paramiko library for the ssh connection and you have to define the rpc for show version (get-software-information), then open the socket to the device on the right port (830) and create the transport using that socket as the connection. Once it’s open, you can then send the rpc and then wait for the end of the rpc-reply. Then close the open session, close the transport and then close the socket. This python code is roughly about 50 lines.

The example can be implemented by writing 6 lines in PyEz.

Subsequently you can follow my already written post of My Second Step towards Automation: Install the PyEZ Library and Connect Your Remote Device and My Third Step towards Automation: How to map Junos Commands to PyEZ RPC.

So finally as closing comments I am not expert and can't explain the pros and cons each and every programming language but would suggest to start your learning with Python or PyEz and start writing your first famous “Hello World” program.
Click Here To Read Rest Of The Post...

Do I need to be programmer before learning Automation, SDN and NFV technologies?

Network Engineers are worried about the skills required to learn about the next generation technologies like SDN and NFV. Every time when someone talk about SDN and NFV, I always think that do I need to learn any kind of programming language like C, Python, Perl, SLAX, RUBY etc.? Does my CCNA, CCNP, CCIE, JNCIA, JNCIS skills are no more required? There are lot of questions comes in my mind about job security also. At times, I assume will companies hire or retain only those engineers who understand programming better than BGP or OSPF or ISIS.

Automation is the new buzz word in the industry. Every customer wants to automate their entire infrastructure without understanding how does it work. As per my understanding automation means is to shorten the completion cycle of current job by writing some scripts or loops. But as industry perspective, we think automation means programming and without having its knowledge how someone can automate any kind of job.

In IT industry, automation was being used since long. Ansible is the right example of IT Automation industry. But in networking automation was also used since long. The best example of automation is to run a script in the night which normally takes the backup of the current configurations of network elements. Second best example of automation in networking is Network Management System (Vendor Specific)

In Network we are already decoupling control and data plane by implementing route-reflector functionality.

Now the question arises if automation, SDN etc. technologies are already there then why we all are worrying about it. Is it something different of what we are already doing? I would say: Automation, SDN and NFV are bringing customer on boarding faster time to market. Earlier these technologies are only locked with specific vendor but not multi-vendor is required. Now a days if you require route-reflector functionality, in that case you need to order a dedicated router. The same functionality can be leverage by using route-reflector VNF. Route-Reflector VNF has full fledge functionality of route-reflector what we usually get in hardware router. The only difference is that in earlier case hardware and software were tightly coupled together but now it is decoupled.

Again the question is not answered what skills are required for multi-vendor SDN and NFV. Let’s examine the route-reflector example and it will help us to understand what kind of skills are required.

The above example in figure shows if we have to spin up VNF of virtual route reflector, in that case close integration is required among Compute, Networking and Storage. To get the integration done one must understand the below as listed:-
1. Linux OS Fundamentals
2. Basic Scripting or Programming to automate the stuff
3. Networking
4. Storage
5. API Calls
6. GIT
7. Orchestration tools like Pupper, Chef, Ansible and Salt Stack etc.
8. Open Stack

So it’s not all about programming to become Automation, SDN and NFV engineer. It’s all about how do you embrace these technologies with multiple skill set knowledge. It’s jack of all trade and master of none or one. All you need to understand how does the process works and how do you link each and every step with other.

Click Here To Read Rest Of The Post...

SDN NFV Considerations For Customers

What is NFV?

Network Functions Virtualization (NFV) is an alternative design approach for building complex IT applications, particularly in the telecommunications and service provider industries, that virtualizes entire classes of function into building blocks that may be connected, or chained, together to create services.

Various NFV Use Cases

Below are some sample NFV use cases can be evaluated and implemented: 1. virtual Provider Edge (vPE)
2. virtual Customer Premise Equipment (vCPE)
3. virtual Security
4. virtual Router
5. virtual BNG
6. Service Chaining
7. virtual Packet Core

What Does All This Mean For Customer?

NFV should be viewed as a transformative technology for Customer. The potential applicability for NFV solutions, as well as potential benefits, are almost endless:
Start Farm as a Consumer of NFV Solutions and Services – There is little doubt that Service Provider offerings will be changing dramatically in the coming years and what used to be table stakes for incumbent Tier 1 TELCOs, Cable MSOs and other traditional providers will be up for grabs. Traditional providers realize this and are moving quickly to embrace SDN, NFV and other disruptive technologies. The end result will be increased competition in the market and downward pressure on pricing. Customer should look to partner with traditional SPs (or other SPs) on innovative NFV based product and service offerings while keeping in mind the potential barriers for successful technology adoption.

NFV Deployment Models

The number of potential NFV deployment models is extensive and will likely grow over time. DC-based NFV is the first likely be the deployment model. The potential value of NFV extends beyond the DC. For providers, NFV solutions will extend beyond the DC to the point of presence (POP) and customer premise.

NFV enablers:
1. Improved x86 hardware performance

2. Maturity level of hypervisor technology

3. Automation and orchestration solutions

NFV Value Proposition
1. Reduce CAPEX/OPEX
2. Increase service agility
3. Accelerate service creation (hardware abstracted cloud based delivery)
4. Reduce energy costs, and
5. Enable dynamic service driven platforms

Click Here To Read Rest Of The Post...

Facebook Introducing Open/R Modular Routing Platform

Open/R generalizes the concept of a replicated state database found in well-known link-state routing protocols such as OSPF and ISIS. It uses this as an underlying message system upon which is used to build multiple applications. Distributed routing is just one of the applications that leverages this message bus. Facebook is leveraging Thrift for all message encoding and use the well-documented and mature open source ZeroMQ library for all message exchange, whether it's intra-process or inter-process.

ZeroMQ typically uses TCP to establish transport connections and allows for flexible message patterns (with PUB/SUB being one important example) that we actively leverage. While it might sound heavyweight compared with OSPF and ISIS, which use their own “lightweight” transports, we haven't found this to be an issue in modern networking hardware, such as the devices we use for Terragraph or the Wedge and 6-pack boxes running FBOSS in our data center networks. On the plus side, using ZeroMQ saves a lot of work implementing and testing the low-level aspects of the system, and it allows us to use the same framework for intra-application and inter-application messaging.

Link to Post
Click Here To Read Rest Of The Post...

All About Juniper JET Automation Framework

JET is a framework which means all the features ties together that enables JUNOS to be more open and programmable.

There are four big components of JET
1. Python: Python 2.7.8 is supported on all JUNOS devices. By using Python users can develop and execute Python scripts on JUNOS.

2. JSON: JSON is popular data exchange program because of it’s simplicity, light weight and rich native support in several programming languages. Most of the python programmers use JSON as data exchange program. With this help now JUNOS operational show commands can display data in JSON format also along with XML format. JUNOS configuration can be provided directly in JSON format which can help programmer to write code in python and push configuration on box without having worry of XML.

3. Fast Programmatic Configuration Database: It is fast programmatic configuration database used by JUNOS and gives access to controller’s applications which are pushing fast state changes onto JUNOS. SDN applications can make the changes at very high rate with 1000 of configuration changes per second with no configuration validation. The onus of configuration validation will be taken care by the external SDN controllers and applications.

4. JET API: SDN requires programmable interface for fast rate of configuration changes with multiple instance of databases without the contention of database resources. JET APIs are AVATAR of JUNOS SDK which enables APP developer to program the JUNOS control and data plane. JET APIs constitutes of 5 things as mentioned below
a. Route
b. Interface
c. Firewall
d. Management APIs
e. Notifications

JET APIs framework is language and Operating System agnostic which means APP developer can use any of the language and OS of their own choice. The APPS which are written will be binary compatible and decoupled from the JUNOS releases. All the APIs exposed externally by JET will be used internally as well.
Click Here To Read Rest Of The Post...

What is Virtual Network Function or VNF?

In a Network Functions Virtualization(NFV) architecture, a virtualized network function, or VNF, is responsible for handling specific network functions that run in one or more virtual machines on top of the COTS hardware. In a virtualized environment, a virtual network function means that a company has taken the software that actually performs a specific function, abstracted it from their own hardware, and packaged it to run on any standard server.

The primary goal for NFV is to decouple software implementations of network functions from the compute, storage, and networking resources in the network. The software that performs the specific network function is generally called Virtual Network Function aka VNF. Examples of VNFs are P-Gty, GGSN, Session Border Controller and Virtual Router. When a function of ROUTER or UTM is virtualized it is called VNF. When we club all the sub functions of VNF into one it become virtual ROUTER or virtual UTM.
Click Here To Read Rest Of The Post...

Segment Routing Based MPLS Vs Classic MPLS

Previous post has already covered why segment routing is required with all it's basic information. This post is mainly focusing on difference between SR Based MPLS Networks Vs Classic MPLS Networks.

	Segment Routing Based MPLS	Classic MPLS
MPLS Transport	IGP	IGP + LDP
IGP/LDP synchronization	Not Required	Required and Added More Latecny in Convergence
50msec FRR	IGP	IGP + RSVP-TE
Extra TE states to support FRR	No extra state	Extra states to manage
Optimum backup path	Yes	No
ECMP-capability for TE	Inbuilt	No
TE state only at headend	Yes	No (n^2 problem at midpoint)
Seamless Interworking with classic MPLS	Yes	NA
SDN Support	Yes	No
Routing	Constraint Based (Source can Define)	Destination Based + RSVP-TE
Link information	(Bandwidth, IGP metric, TE metric, SRLG ) is flooded throughout the IGP domain	No
Path Calculation	CSPF or By Using Centralized Controller	IGP + RSVP-TE
Scalability	High	Low
Operations and Troubleshooting	Low	High

And here is the rest of it.
Click Here To Read Rest Of The Post...

Layer 3 MPLS VPN with Segment Routing - Nodal Segment

Traditionally Layer 3 MPLSVPN service requires two labels; VPNv4 Label and LDP (Transport Label). LDP is used to distribute the transport labels within service provider domain. But let’s see how Layer 3 MPLSVPN service will work in case of Segment Routing.

Below is the topology which has configured IGP and MP-iBGP for Service Provider network. CE1 and CE2 are two sites of same customer which are part of same vrf. This service provider core is free from LDP.

Segment Routing is used for transport label however MP-iBGP is used for VPNv4 labels. On every SR capable router, Loopback interface is configured as Node segment ID which is also called as Prefix segment ID.

Label 200 is Node/Prefix SID of PE2 and is advertised in the IGP protocol as SR label which is part of SRGB. For PE1 reaching CE2; BGP next hop is a PE2 loopback. PE2 loopback is flooded as a label of 200 in the IS-IS sub-TLV extension or OSPF Opaque LSA.

PE1 pushes label 200 as transport label and 500 as inner label.
PE1 and P1 don’t change the transport label and send the packet to the P2. P2 receives an implicit null label for the loopback of PE2, P2 does PHP (Penultimate Hop Popping), and thus only the VPN label is sent to the PE2.

Click Here To Read Rest Of The Post...

Basics Of Segment Routing

Segment Routing is a new technology that will increase the benefit to IP and MPLS networks. It is an alternate to LDP and RSVP which means without using the LDP and RSVP we still can generate and distribute the transport labels and steer the traffic without using the RSVP signalling. Segment routing is based on label switching but for labels generation and distribution LDP and RSVP is not used. Segment Routing is an extension to an IGP (OSPF/ISIS). Labels are called segments in Segment Routing.

As per IETF draft “Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based.

Segment routing uses IP control plane but MPLS and IPv6 as data plane for its operation. There are two main components of Segment Routing:-
1. Control Plane:- Generation and distribution of transport labels across the Segment Routing domain by using IGP (OSPF/ISIS)
2. Data Plane:- Add the labels (Segments) on the packet header

Different Type of Data Plane Operation supported by Segment Routing
1. Continue:- Forwarding action based on active segment
2. Push:- Add a segment to the SR header of the packet and set that as Active Segment
3. Next:- Mark the next segment as the active segment and execute the instruction encoded by the new active segment

Comparison between MPLS and Segment Routing Operation

Segment Routing Operation	MPLS Operation
Segment Routing Header/Segment List	Label Stack Header
Active Segment	Topmost Label
Push	Label Push
Next	PoP
Continue	Swap
Segment Id	MPLS Label

There are two main types of segments in Segment Routing:-
1. Node Segment (Node/Prefix SID):- Node segment ID which is also called as Prefix segment ID is used to specify loopback interface of Segment Routing enabled device. The forwarding is associated with Node segment ID. The operator assigns a domain wide unique Node segment ID for each router in the network. This can be done manually or using a centralized controller (SDN Use Case).



2. Adjacency Segment:- Each router will assign a locally significant segment ID for each of its IGP adjacencies and it is not globally unique like Node/Prefix SID. Segment Routing enabled routers allocate Adjacency segment ID for their all attached interfaces automatically when the segment routing is enabled on the router.




Click Here To Read Rest Of The Post...

How to make network ready for SDN/NFV?

Since long, Telecom Service Providers are procuring network equipment and appliances – such as core, edge, aggregation routers and switches. But new approach is required for these processes have to be modified to exploit the flexibility, agility, faster go to market and cost-savings in virtualizing these functions. Operators are not going to replace all their existing networking gear and operational support systems in one step and replace them with software running on top of servers. At 30,000 the software approach looks very good but in fact it is too much expensive and risky. The migration to NFV will take in shorter steps wherein at first step SP should build infrastructure for virtualization and add the required skill sets in the operation team to support it. The next step both the networks must co-exist and work together. In the final step, SP can remove the legacy stuff and complete migration can be done on SDN/NFV.

As I have already mentioned, at 30,000 feet it looks very intuitive and very good in presentation slides but the real challenge is totally different. We need to understand the different kind of networks, business processes and business requirements. Once this is done, need to understand how network agnostic software layer can be laid to support every function to achieve business objective. To deliver services end to end in a hybrid, multi-partner network of networks, you need a migration plan that uses best practices to ensure you are able to maintain service levels without degrading customer experience.

If you would like to make your network ready for SDN/NFV, you need to take the following steps:-
1. Add strong NMS
2. Start Migration of Physical Servers to Virtualized Servers
3. Add the automation layer to spin the new VMs, delete VMs as per the threshold defined
4. Building Overlay Networks
5. Start Adding open controllers to support network APIs
6. Merge Network and Server infrastructure in common software layer

As a result of this, you will get faster go to market, competitive, saves lot of capex and opex, get rid from the logistics and better customer experience.
Click Here To Read Rest Of The Post...

What is Network Functions Virtualization (NFV)

Network Operators’ networks are populated with a large and increasing variety of proprietary hardware appliances. To launch a new network service often requires yet another variety and finding the space and power to accommodate these boxes is becoming increasingly difficult; compounded by the increasing costs of energy, capital investment challenges and the rarity of skills necessary to design, integrate and operate increasingly complex hardware-based appliances. Moreover, hardware-based appliances rapidly reach end of life, requiring much of the procuredesign-integrate-deploy cycle to be repeated with little or no revenue benefit. Worse, hardware lifecycles are becoming shorter as technology and services innovation accelerates, inhibiting the roll out of new revenue earning network services and constraining innovation in an increasingly network-centric connected world.

Network Functions Visualization(NFV) aims to address these problems by leveraging standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which could be located in Datacentres, Network Nodes and in the end user premises. We believe Network Functions Virtualisation is applicable to any data plane packet processing and control plane function in fixed and mobile network infrastructures. NFV decouples the network functions, such as network address translation (NAT), firewalling, intrusion detection, domain name service (DNS), and caching, to name a few, from proprietary hardware appliances so they can run in software.

Virtualising Network Functions could potentially offer many benefits including, but not limited to:
1. Reduced equipment costs and reduced power consumption through consolidating equipment and exploiting the economies of scale of the IT industry.
2. Increased speed of Time to Market by minimising the typical network operator cycle of innovation.
3. Availability of network appliance multi-version and multi-tenancy, which allows use of a single platform for different applications, users and tenants. This allows network operators to share resources across services and across different customer bases.
4. Enables a wide variety of eco-systems and encourages openness.

Click Here To Read Rest Of The Post...