SDN & NFV and what's the Cloud?
Abbreviations SDN and NFV recently sound more and more and sound together. In tenders, telecom operators require manufacturers to support SDN and NFV, because We are confident that these technologies have a positive effect on OPEX, CAPEX and TTM. Fast Internet surfing shows that SDN is Software-Defined Networking, and NFV is Network Functions Virtualization. Both technologies are connected with virtualization and with networks, i.e. at first glance it seems that they are very similar, if not the same thing. Let's figure out if this is true! The Google Trend check first confirms the hypothesis: the trend of the “SDN and NFV” query starts in 2013:
But then it turns out that the topic of the Software-Defined Network begins to rise much earlier - from 2008:
')
We start to understand.
SDN was born in the depths of data centers. In a nutshell, the problem with the network was the following.
The classic switch routes traffic flows according to the rules that need to be configured in the switch itself. If there are 10-20 switches, then they can still be configured manually, and in data centers with hundreds or thousands of switches, the task turned into an unsolvable one. Simplified diagram illustrating life before SDN:
Those. for the data stream to be routed through 3 switches, you must configure each switch separately. What does SDN offer? From the modern point of view on architecture - nothing new: the division into layers and the standardization of interfaces:
In the lower layer “Infrastructure” there are simple switches that can only route traffic. The routing tables are spread out from the central controller located in the “Management” layer. To do this, use the standard protocol "OpenFlow". OpenFlow is a standard that the Open Networking Foundation (ONF) has been developing since 2011. And the first version of the standard appeared in 2008, it becomes clear where the growth of the trend “Program-defined networks” comes from. On the top layer are “Applications” for managing, configuring and monitoring. API to it is not standardized. Thus, the configuration of switches is centralized, the configurations are automatically spilled - a victory over OPEX and TTM. Switches have become cheap and standard - save CAPEX. For standard data centers - a big victory, but for telecom operators, happiness did not come.
Operators still have a problem - a large number and variety of network functions, examples of well-known: NAT, firewall, DPI. Each manufacturer delivers its applications on its hardware, and as a result, the proprietary iron zoo accumulates at the operators, which, again, must be synchronously configured when new commercial initiatives are introduced for subscribers. Those. This is the same problem with switches, but at a higher level. What did the operators come up with? They merged and under the auspices of ETSI (European Telecommunications Standards Institute) released the ETSI NFV standard. Picture from the standard illustrating the problem and solution:
The first version of the ETSI NFV standard came out in 2012 (yeah, that's where Google Trend is growing). Let's take a closer look at the standard, simplified diagram from the document “ETSI GS NFV-EVE 003”, illustrating the architecture:
Let's figure it out. On the right, the NFV MANO (Management and Orchestration) is only the part that ETSI specifies. The fact that the left - only recommendations. In principle, this part may differ from different manufacturers, but, as practice shows, everyone fits their solutions into this general scheme.
On top of the OSS / BSS are standard carrier systems - billing, charging, charging, CRM, customer self-service, etc. They both were, and remain, and are connected with NFV only one specified interface (Os-Ma). I will tell you about the functions of interfaces in more detail in another article, but now I need to understand the big picture. Below are the VNF (Virtualized Network Functions) - these are just network functions that now work on standard hardware in a virtual environment. EM (Element Management) - management of network elements. EM provides FCAPS (fault, configuration, administration, performance, security) functionality for VNF. It is not very clear why they were introduced into the EM standard at all? I think in order not to make these functions in OSS / BSS, so as not to frighten operators with the need for improvements in this circuit. Manage VNF - VNF Managers (VNFM).
VNF Managers are supposed to be sold by VNF manufacturers, because Manufacturers know best how to manage their VNF.
NFV Infrastructure (NFVI) - standard (COTS) equipment with a hypervisor layer and virtualization is located under the VNF layer. Hardware and virtualization are managed by VIM (Virtualized Infrastructure Manager). Manufacturers of virtualization systems took just the bottom layer. Linux, OpenStack and a few dozen companies have organized the Open Platform for NFV (OPNFV) project. VMWare, of course, implemented its vCloud NFV alternative:
The main element of the NFV, the NFVO (NFV Orchestrator), controls all these farms. Which manufacturers implement the elements of the NFV Orchestrator? To date, there are also two alternatives. ETSI announced the launch of the project - Open Source MANO (OSM) and Cloudify offers its honest “pure-play cloud orchestration platform” , which works with both OpenStack and VMWare:
Well, everything with NFV, sort of, figured out, but along with the advantages of NFV today we see a number of problems:
Thus, we see that the NFV standard has room to grow! Wait, where's the SDN?
SDN provides for NFV network interface virtualization and network connectivity for VNF. Take for example the elements from OpenStack: the virtual switch "Open vSwitch" and the SDN controller "Open Daylight". Put them in the NFV, and now it’s clear where the SDN is:
Can SDN exist without NFV? Of course, maybe - this is what we saw at the beginning of the article. Can there be NFV without SDN - the answer is the same, but you will need to configure the network interfaces and connectivity manually, i.e. We are really seeing the synergy of SDN and NFV. It became clear that these are not synonyms, but two big differences!
Thus, while watching the development of the standard and look forward to real success stories!
And what have the clouds? About this in the next article, "Clouds like love."
But then it turns out that the topic of the Software-Defined Network begins to rise much earlier - from 2008:
')
We start to understand.
SDN - problem and solution
SDN was born in the depths of data centers. In a nutshell, the problem with the network was the following.
The classic switch routes traffic flows according to the rules that need to be configured in the switch itself. If there are 10-20 switches, then they can still be configured manually, and in data centers with hundreds or thousands of switches, the task turned into an unsolvable one. Simplified diagram illustrating life before SDN:
Those. for the data stream to be routed through 3 switches, you must configure each switch separately. What does SDN offer? From the modern point of view on architecture - nothing new: the division into layers and the standardization of interfaces:
In the lower layer “Infrastructure” there are simple switches that can only route traffic. The routing tables are spread out from the central controller located in the “Management” layer. To do this, use the standard protocol "OpenFlow". OpenFlow is a standard that the Open Networking Foundation (ONF) has been developing since 2011. And the first version of the standard appeared in 2008, it becomes clear where the growth of the trend “Program-defined networks” comes from. On the top layer are “Applications” for managing, configuring and monitoring. API to it is not standardized. Thus, the configuration of switches is centralized, the configurations are automatically spilled - a victory over OPEX and TTM. Switches have become cheap and standard - save CAPEX. For standard data centers - a big victory, but for telecom operators, happiness did not come.
NFV - problem and solution
Operators still have a problem - a large number and variety of network functions, examples of well-known: NAT, firewall, DPI. Each manufacturer delivers its applications on its hardware, and as a result, the proprietary iron zoo accumulates at the operators, which, again, must be synchronously configured when new commercial initiatives are introduced for subscribers. Those. This is the same problem with switches, but at a higher level. What did the operators come up with? They merged and under the auspices of ETSI (European Telecommunications Standards Institute) released the ETSI NFV standard. Picture from the standard illustrating the problem and solution:
The first version of the ETSI NFV standard came out in 2012 (yeah, that's where Google Trend is growing). Let's take a closer look at the standard, simplified diagram from the document “ETSI GS NFV-EVE 003”, illustrating the architecture:
Let's figure it out. On the right, the NFV MANO (Management and Orchestration) is only the part that ETSI specifies. The fact that the left - only recommendations. In principle, this part may differ from different manufacturers, but, as practice shows, everyone fits their solutions into this general scheme.
On top of the OSS / BSS are standard carrier systems - billing, charging, charging, CRM, customer self-service, etc. They both were, and remain, and are connected with NFV only one specified interface (Os-Ma). I will tell you about the functions of interfaces in more detail in another article, but now I need to understand the big picture. Below are the VNF (Virtualized Network Functions) - these are just network functions that now work on standard hardware in a virtual environment. EM (Element Management) - management of network elements. EM provides FCAPS (fault, configuration, administration, performance, security) functionality for VNF. It is not very clear why they were introduced into the EM standard at all? I think in order not to make these functions in OSS / BSS, so as not to frighten operators with the need for improvements in this circuit. Manage VNF - VNF Managers (VNFM).
VNF Managers are supposed to be sold by VNF manufacturers, because Manufacturers know best how to manage their VNF.
NFV Infrastructure (NFVI) - standard (COTS) equipment with a hypervisor layer and virtualization is located under the VNF layer. Hardware and virtualization are managed by VIM (Virtualized Infrastructure Manager). Manufacturers of virtualization systems took just the bottom layer. Linux, OpenStack and a few dozen companies have organized the Open Platform for NFV (OPNFV) project. VMWare, of course, implemented its vCloud NFV alternative:
The main element of the NFV, the NFVO (NFV Orchestrator), controls all these farms. Which manufacturers implement the elements of the NFV Orchestrator? To date, there are also two alternatives. ETSI announced the launch of the project - Open Source MANO (OSM) and Cloudify offers its honest “pure-play cloud orchestration platform” , which works with both OpenStack and VMWare:
Well, everything with NFV, sort of, figured out, but along with the advantages of NFV today we see a number of problems:
- Only two manufacturers offer a solution for VIM: OpenStack and VMWare
- It does not work on the IT virtualization system to build NFV. At first, we thought that we were taking an IT virtualization system, we screwed it up a bit, and it turns out NFV. But NFV tasks are too specific. For example, deployment on bare metal servers, the need for a distributed structure, a greater number of WAN links and external traffic.
- Higher hardware requirements, performance, response latency
- Configuring NVF does not fit into templates
- Vendor-lock cannot be avoided even using OpenStack. need technical support, and OpenStack every manufacturer sharpens for themselves
Thus, we see that the NFV standard has room to grow! Wait, where's the SDN?
SDN and NFV
SDN provides for NFV network interface virtualization and network connectivity for VNF. Take for example the elements from OpenStack: the virtual switch "Open vSwitch" and the SDN controller "Open Daylight". Put them in the NFV, and now it’s clear where the SDN is:
Can SDN exist without NFV? Of course, maybe - this is what we saw at the beginning of the article. Can there be NFV without SDN - the answer is the same, but you will need to configure the network interfaces and connectivity manually, i.e. We are really seeing the synergy of SDN and NFV. It became clear that these are not synonyms, but two big differences!
Thus, while watching the development of the standard and look forward to real success stories!
Clouds
And what have the clouds? About this in the next article, "Clouds like love."
Few links
- Software-defined data center
- SDN and NFV: how it works on the carrier network
- SDN and NFV many articles: sdnblog.ru
- SDN and NFV many articles in English: www.sdxcentral.com
- NFV MANO: What's Wrong & How to Fix It
The following articles
- Clouds like love
- Interfaces and Functional Blocks NFV
- SDN and NFV Manufacturers and Cases
- Cooking NFV at home
- BigData and NFV - is there a connection?
Source: https://habr.com/ru/post/316324/
All Articles