Network as part of the application
Hello my friend,
Almost daily some new abbreviations describing technical products or approaches appear on the market. Some of them live only moments, whereas others may stay for quite a few years. Recently, I have been talking to a colleague of mine about SDN (Software Defined Networking). We were discussing the topic thoroughly:
1) What are the different solutions or approaches to SDN conceptually?
2) What are the solutions which different vendors offer to the market?
3) How do these solutions work?
4) What are their pros/cons?
The abbreviation SDN is used (or misused) so much nowadays, that even people not in the networking industry have heard about that. Consequently, for different people the term SDN has different meaning. And this is absolutely OK, because today under the umbrella of the SDN term, there exists a variety of solutions focusing on different markets (Data Centres, Enterprise, Service Providers, Clouds) and having different architectural principles (underlay or overlay, open-source or proprietary). Navigating across these solutions might be challenging. Therefore, it is important to establish the direction you want to take.
To establish the course, you have to answer the question “what is the network’s role in your business nowadays”. Its ultimate goal, obviously, is to send packets from endpoint A to endpoint B. But what are these packets? Think about it for a moment.
Why do you need a network?
But what are these packets? The answer to this question fully depends on the way you use the network. The current trend for digitalization in all parts of life requires more and more traditional services being deployed as an application that you can access from your smartphone or laptop. It means the network plays a key role spanning the pieces of the application together and with the customer.
For example, say you’re buying hosting services from The Hut Group. You can buy these services online anytime and anywhere and quickly. Of course, if you want to have 100000 dedicated servers in certain data centre location that might require some time to install and wire them. On the other hand, if your request is about a reasonable amount of the resources, this is something that could be fully automated and you can expect that your request is processed instantly without all the paperwork.
That is where the SDN comes on the stage to help.
What is SDN?
For me, SDN is not about the particular products or vendors. For me, SDN is about the possibility to do things differently compared to the traditional approach driven by ticket systems, spreadsheets and humans.
For me, SDN has the possibility to give the networking setup the speed and the flexibility your application requires. Why is it important? Thinking about the mentioned example of buying hosting services, you typically need the servers to host your application. It means that the servers might be connected in a certain manner:
1) Internet uplink (throughput, available traffic per month)
2) Security zones (front-end vs back-end).
3) ACLs to allow only certain type of the traffic towards servers and so on.
All these steps should be done in an automated manner without involvement of the humans in the provisioning process.
How does network provisioning look without SDN?
In a traditional (or legacy) world, the vast majority of the network implementation is done based on some sort of ticket system bundled with change management systems. All such systems have a noble purpose to minimize the risk of the network outage by tracking all changes and verifying the details of the change. In reality, the risk assessment of the network change is quite often done by the same engineers who deploy the change. From my experience participating in various change boards, I have very rarely seen any experts who can independently verify the proposed network changes. Such a situation destroys the primary goal of any change board, making them fairly useless for the vast majority of cases. Then, once the assessment is done and change is approved, the network engineers schedules the change implementation in a maintenance window.
All these steps create unnecessary delay for the customer and burden for the operational team. Both are equally unhappy. Moreover, the risk of the network change isn’t somehow decreased. There is definitely a more efficient way of doing things.
How does network provisioning look with SDN?
Before explaining the details, I need to admit and warn you that SDN is not a magic pill that solves all your problems. It is just a tool or a set of tools, which can simplify and speed up your network business, if used properly.
Having said that, the we are going to use this SDN toolkit in a proper way. In the example described earlier in this blog post, we briefly mentioned the tasks required from the network:
1) Configuration of the uplink including IP addresses on the servers and default gateway and shaping/policing for BW limitation.
2) Configuration of the connectivity between the servers.
3) Configuration of the security rules (allowed protocols/ports, etc)
All these tasks have a clear definition, input parameters and the expected outputs. Speaking in math language, each of these tasks is a function, which has input variables and meaningful output. As such, these input variables can be provided either manually via a network engineer or in a programmatic way from any other application that is the software-defined network (SDN) itself.
So far, we have started forming the requirements to the SDN solution:
1) Input, which is necessary to implement the change. By standardized, we mean two various, but equally crucial aspects.
a. The standardized format (also called a service data-model), which creates the structure of change request by defining: information (router names, interfaces, IPs, protocols, etc) and which format should be present at the function input.
b. The standardized protocol, which is used to feed the function. De-facto standard interface of the SDN controller for the integration with the outside world is REST API.
2) Functions which, in a broad sense, process input variables into output result. In a narrow sense, functions are applications, which are able to process high-level service-oriented data into device-oriented configuration. In the case that the network elements support RESTCONF or NETCONF, it will be remapping values from the initial REST API into RESTCONF/NETCONF with the extension of some low-level parameters. If network elements support only SSH/CLI, it will be a templating engine that can create proper configuration files using CLI commands.
3) Output which is the information necessary for the actual network element configuration. In the same way as for input, there are two parameters:
a. Format, which in this case is the device-specific data-model. It is typically defined by vendor-proprietary or standard (e.g. OpenConfig) YANG models or CLI commands.
b. Protocol which the network elements support. It’s primarily NETCONF for modern device and SSH/CLI for legacy devices. There are two more, but they aren’t widely distributed now: RESTCONF (for various reasons it has lower support level across industry on the network elements) and gNMI (which currently is mainly used for telemetry streaming).
If we think about all these components, we should have the following (or similar) picture in mind:
Such an architecture is supposed to be used for deployment of new services, modification of the existing ones, and removing of deprecated ones.
Also, on the picture above you might have spotted the logical connection towards the change management database. This interface is used to automatically update the status of the change without compromising the speed of the change delivery.
Summing up
The real idea of SDN is to allow your network to be an enabler for your application rather than a constraint. This is possible, when placement of the configuration on and off the network is fully automated and driven by the request from the associated application, rather than by humans. This blog post is the first in the series about the network as a service (or network as code or network as whatever) discussion. Take care and goodbye!
Cheers,
Anton Karneliuk
We’re recruiting
Find out about the exciting opportunities at THG here:
