SDN, NFV and SD-WAN work together
The network is a collection of a large number of coordinated behaviors, so what we face It’s no surprise that there is a correlation between key networking technology “revolutions.”
However, the relationship between these key network technologies is not very clear.
Software-defined networking (SDN), network functions virtualization (NFV) and software-defined wide area network (SD-WAN) share some technical elements, and they may also have associated business opportunities.
In fact, these relationships may be critical, so we need to consider them further.
SDN, if we adopt a purely conceptual white-box switch or virtual switch controlled by the OpenFlow protocol, it is a true use of a centralized controller to define the network routing.
Each device is told how to process the corresponding packet based on the packet header, and combines the processing instructions to create a route for forwarding the traffic.
It can be seen that SDN is related to routing, that is, related to network connectivity.
If you "own" a network, whether it is a local area network (LAN) or a wide area network (WAN), you can use SDN.
Because SDN can be applied to networks created by real physical facilities as well as networks created by tunnels, it does notYou don't need to have fiber optics, microwaves or anything like that.
You don’t have to have a white box device either.
Many legacy switches/routers also accept the OpenFlow protocol and can also use virtual switches or routers.
You must have a switch/router as a network element.
Currently the largest SDN application is in the cloud, where SDN is used to connect cloud components in data centers.
NFV is related to the software features used and is hosted in something that provides some set of network features instead of using specific equipment.
The so-called NFV, as a standard specification, describes how to deploy, connect and manage these network features.
What features are there? Typically NFV targets high-level network features, like firewalls, encryption or VPN encapsulation.
It can also be used to deploy services like DNS and DHCP, and even instances of virtual switches and routers.
NFV is related to service characteristics/elements.
So you can use NFV to deploy SDN elements, and if you consider doing that, it means that SDN can be used to connect those NFV elements that are deployed on servers like servers.
In NFV applications, you can also use SDN almost anywhere you need connectivity.
Where does NFV come from? NFV is designed for network operators who need to deploy services with complex features.
In theory, NFV can be used by enterprises, which we will explore further below.
SD-WAN is the pioneer of the three, and probably the most difficult to truly understand of the three.
The basic principle of SD-WAN can be understood as establishing a "virtual network" on one or more different physical networks or network services, as long as the mapping between virtual and physical can be done well. < /p>
There is no need to know what technology is being used for things inside and outside the virtual network.
So you can connect and establish a VPN between sites through the MPLS VPN service and other tunnels that connect the network, or you can. You can also mix the two services across some or all sites, using them to back up or extend each other, or for different types of traffic.
Unlike SDN And NFV is something that is added to the network in some way.
SD-WAN is something that relies on the edge of the network structure.
It is the element that SD-WAN creates.
SD-WAN not only includes the mapping between traffic and virtual-physical networks, but also includes network services. Option management, so virtual network users do not need to be involved in pipe management.
Interestingly, for enterprises, SD-WAN may be more effective than SDN Practice the principles of SDN.
The original SDN concept from Nicira is an overlay network that does not require any changes to the infrastructure used for connection, whether it is a two-layer or three-layer network. ).
Overlay networks allow users to be independentBy managing connectivity over transport, segmented networks have no operational penalties and accommodate multiple service options.
SD-WAN codifies all of this.
The "basic" relationship between the three technologies will be described below, but we will actually talk about some changes that will create a closer relationship.
We look at these changes through some technical lenses, but I will continue to use SD-WAN as a framework because I hope to be able to explain it more clearly.
As mentioned above, SD-WAN is a technology at the edge of the network structure.
Can be deployed through NFV technologies now known as "service chaining" and "virtual CPE (vCPE)".
The idea is that if you need to deploy SD-WAN, you can add those features to the edge device along with other security technologies.
These don’t take too much time. In my opinion, this is the best way to deploy vCPE, because current enterprise sites already have basic networks such as security tools implemented in CPE. A few of them have also adopted SD-WAN.
Another reason operators will like using SD-WAN as a vCPE solution is that SD-WAN creates VPN services without tying them to a specific implementation.
You can create a VPN using current MPLS methods, or using an Internet overlay, or through SDN and embedded virtual routers, you name it.
This is very useful for operators who, at some scale, have to contend with the existence of multiple access methods or the evolution of access methods.
It is also critical outside of scope because you can provide network scalability for MPLS (or other VPN models).
SDN can also set the forwarding process for devices in SD-WAN, just like the virtual switch that has been created.
As mentioned above, you can use SDN as a service item in SD-WAN, which allows the operator's business services to be connected between SDN-based and traditional implementations.
Some operators will see this connection as a risk, because customers will adopt SD-WAN solutions and get rid of MPLS-based VPNs. This may also be why we do not see SD-WAN emerging in NFVvCPE. reason.
In the long run, I think SD-WAN needs further self-adjustment.
The SD-WAN essence of the virtual overlay network is hidden in many SD-WAN product positioning.
It may be that vendors are afraid that other implementations will increasingly replace traditional vCPEVPN solutions.
As for the problems caused by this kind of trade protection, I believe that the virtual overlay network will eventually develop further, and we will move towards a new commercial network based on virtual links and virtual switches/routers.
SD-WAN vendors would be wise to consider entering this field now.
In fact, the relationship between SD-WAN, SDN and NFV has not yet developed very maturely. So far, technology is not a problem, but on the other hand, the complex business issues reflected are more obvious.
Network operators and now major network equipment vendors alike are afraid of adopting SD-WAN because it will dilute current spending on traditional VPNs or VPN-related equipment.
It is difficult to promote the development of a technical concept without a big player who can promote it and provide analysis reports.
We do have many reliable SD- WAN solutions, so if some vendors can relate to SDN and NFV, they can move the ball forward. /p>
