Video
Podcast | Cyber trends – what should we know?
Cyber security is a process that we need to approach comprehensively. On-the-spot action can give the illusion that ‘som...
Podcast | SDN Explained – Future of SDN or current directions of software defined networking development
In the last episode we’ve already talked a little bit about Software-Defined Networking as a philosophy of network development and have covered the different perspective on how the network works in general.
Piotr:
Telecommunications technology is changing right before our eyes. What was once a dream is now becoming a reality. Like SDN, or Software-Defined Networking, a philosophy that took shape around the year 2010 and today is conquering the telecommunications technology worldwide and creating a new market estimated to be worth as much as $43 billion in 2027. In this program, I talk to people who create solutions based on the SDN philosophy: developers, architects, analysts. That is, experienced people who simply know a great deal about programmable network technologies.
Welcome to the second episode of the SDN Explained podcast. Piotr Mierzwiński.
Today our guest is Rafał Szwedowski, SDN Architect at EXATEL.
Piotr:
In the last episode we’ve already talked a little bit about Software-Defined Networking as a philosophy of network development and have covered the different perspective on how the network works in general. I remember one statement in particular: the SDN philosophy can be described as a slow revolution. The changes are unhurried, but profound. We already know that from around 2010 – which is when this philosophy really came into being – until today, the approach underwent significant changes. Can you predict how it will develop in the future? What are the directions for further evolution?
Rafał:
This is a very good question. A dozen or so years ago, SDNs and the Openflow protocol were seen as the same thing. For a while there were attempts to deploy it in various technologies. Because, as we’ve talked about recently – Openflow is mostly used in packet networks; however, as we know, there are also networks of a more physical nature, such as the optical networks which switch some sort of time containers, and radio networks. There is a great number of such instances and the protocol cannot be applied in each case. At that point everyone realized that these concepts, paradigms, is exactly what they want. They require programmability and independence from hardware suppliers. So that’s more or less the direction in which we are going now.
Piotr:
That is, we have a certain amount of independence that gives us some ability to create this network, how it functions and what it delivers to us. Because the network doesn’t just provide us with data transmission, but also with knowledge about how it operates. You mentioned that the basis of this enterprise, or this philosophy, was the Openflow protocol. Is this the only protocol that is available at the moment?
Rafał:
These protocols are very numerous. As far as packet networks are concerned, programmability went to the next level when solutions like P4 language had been developed. The protocols are also related to these solutions. What does next level programmability mean? In Openflow protocol we have some headers defined, which we can process, and then we can match this traffic, passing it from one port to another. That is where it’s all set. The protocol was built on the basis of what was available at the time. With the P4 language, we are able to go a level higher and define by ourselves even the headers we want to process. It is quite interesting because with P4 we can write a program that compiles and we can do Openflow on the basis of this program. This is pretty amazing. The question is to what extent do we need that much programmability. On the other hand, this is a direction that is being developed for packet networks. In the case of other technologies, these interfaces must look different. There is no package here. It is something physical – we just need something different.
Piotr:
The package or protocols themselves are just tools, something that allows us to “dress up” and quantify ordinary system operation. However, it is interesting to see in which direction this whole philosophy will develop, if these several years have brought such big changes. What is next? What will happen in 5 or 10 years when it comes to SDN?
Rafał:
There’s a word that’s been very fashionable for some time now, and it’s more and more commonly used – it’s disaggregation. That’s what I was talking about. Disaggregation means that these solutions will be independent from vendors. This would be beyond amazing given the fact that in the past the suppliers were providing everything in bundles. They provided a number of devices, even when it comes to optics. The following is also a good example – if we wanted to use some optical device, we would have to buy from the supplier a filter, an optical distribution frame and a transponder; now the aim is to ensure that even these individual small elements do not have to be purchased from the same supplier by developing some abstract, programmatic description of the part, which you can then combine freely. At this point this is applicable to literally every technology that is available. The maturity of this solution is demonstrated by the long-awaited deployment on AT&T’s network; the solution is called OpenROADM. It enabled this operator – one of the largest in the United States and worldwide – to deploy such an optical solution. This work took 5 years to complete. It was a big step because a lot of equipment suppliers claimed: “You will not be able to do that. We’re the only ones who know how to use those filters, how to connect those wires and perform all the other tasks.” And yet we succeeded.
Piotr:
Software developers gained advantage over hardware suppliers?
Rafał:
Exactly. Someone described hardware in such a general way so as to benefit from it. And it worked.
Piotr:
It took 5 years to achieve what we refer to as disaggregation, that is to separate the hardware part from the core of the network, so that it could be used in a more unrestrained way. That’s the other thing you mentioned. Are there any other matters that are interesting enough and that are a growth indicators for SDN technology?
Rafał:
Yes. Once we know that we can program this hardware and develop network software by ourselves, another interesting aspect is how we manage it. Some very controversial concepts have appeared in our industry. These were mostly voices of Facebook and Google, who communicated their ideas at conferences: “Look, we’re software developers. We approach problems from that particular perspective. For us, these are programs. We don’t need a Network Operation Center” (i.e. a room where specialists sit and monitor the entire network). They think they can automate even this process. If there is a problem, the right person just gets a text and goes to the relevant location. This is very controversial. It is not easy to write such a software. These problems need to be classified properly – a task that requires the assistance of a large number of professionals. Facebook and Google, however, believe they are capable of doing such a thing. Which is quite interesting, to be honest.
Piotr:
It seems to me that this will be followed by further steps aiming at improving the autonomy of these solutions, with some deeper machine learning than what we’ve seen so far. It’s perhaps a bit like some kind of artificial intelligence (AI). If those who know how NOC works… These are large screen areas that display numerous alerts from each device. The human factor must connect them in some way. If the system was responsible for performing all the tasks, not only in the layer of the solution itself, but also in the analytical layer, we would actually enter a slightly higher level of automation, which is already verging on artificial intelligence.
Rafał:
Exactly. In such cases we already interpret such a network – not even so much as a system or a control plane, but the whole network – as an autonomous system. It may be that a human will be needed to physically put the device in an appropriate place and connect it – that is hard to automate. Although I can also imagine drones flying around and placing these devices at a designated spot. The other thing is – a person who has particular requirements can just click on some service and it will be provided to them. It’s not like in the past we couldn’t correlate events in an automated manner. Such software also exists. However, no one has yet dared to minimize the importance of the human factor to such an extent.
Piotr:
The way I understand is that the human factor – colloquially speaking – will slowly be replaced by SDN technology. To some extent, of course. Time will tell. We all know that even the most advanced drone will not dig a cable out of the ground. There are also other issues to consider, such as repairs. Self-repairing fiber optics known from science fiction movies are yet to be invented. But we can already see that SDN technology is evolving in such a direction that the network itself is treated as an independent entity, a software. An OS (Operating System) that will communicate, update itself and somehow learn from or correct its own errors, operating on the basis of standard elements.
Rafał:
Yes, however, it is still an issue of the future.
Piotr:
Not 5, but probably 15 years ahead.
Rafał:
Yes, I hope so. However, one must not forget that Facebook and Google have very good software developers – they kind of dictate the pace in this industry. Be that as it may, the first really serious deployment of a classic, packet-switched network based on Openflow was Google. There was also a wide area network called P4 B4, deployed in 2014. One might say that they brag about it. According to the latest information, the company did not resign and they’re developing this network further, proving that it is possible and thus setting the pace for the whole industry. I can see the operators taking up the gauntlet.
Piotr:
I think they have no choice.
Rafał:
Yes, or so it seems. There have also been instances where “data guys” such as Google have tried to launch some local projects which assumed provision of telecommunications services by the company itself. These projects include for example Google Fiber – an attempt to provide fiber optic services to homes – or Google Balloon… Starlink should also be mentioned here; it shows that not only companies from the telecommunications industry can provide such services. This is also an interesting direction for development.
Piotr:
As far as SDN development is concerned, it should also be noted that so far companies have been operating in various fields: producing, maintaining and developing their devices on the basis of the so-called closed boxes. Thanks to SDN, there is some change in the market, decreasing this fragmentation. You don’t have to be a leading company or an entity with all the technological background to actually launch such a product or solution – even a complicated telecommunication or operator solution – on the market. Or is this some kind of a trend that no longer goes a little bit beyond the SDN segment itself, but can affect the entire economy?
Rafał:
I’m glad that you’ve mentioned that. This market is opening up to small startups, different companies that wish to try their hand. If we examine the OpenROADM case, we might be able to establish a company that at least provides some sort of active filter, transponder or other components. If it is compatible and it works – why not? Before, everything was just like you described it, that is: closed. It was hard to enter the market.
Piotr:
Can we imagine a situation in which, for example, in 5 years, we will have a store for SDN solutions that is similar to current app stores, allowing you to download an app, a program that will have specific functionalities for a particular protocol and can be used for specific purposes? Obviously, someone is going to make money off of such a store. Would it generate enough profit? It has worked out in B2C telecommunications – will it be suitable for Mr Smith, taking into account that basically every software ecosystem, every OS has its own store that is being developed? Isn’t there a connection somewhere?
Rafał:
This is possible, but it would require for every software developer to create a compatible software. I dare say that would be difficult to achieve. There are some organizational bodies that at least try to describe such a system (in very general terms). E.g. describe very generally the network topology, the manner in which services are correlated, how to control all that. This is done with the use of very general network abstract notions. However, even within this scope, these organizations (for instance: IETF, ONF) cannot reach an agreement. There are just such young models here that are very competitive with each other. We might say that there is a war in the market and it’s not clear which entities will decide on a particular model; these decisions are the most crucial for further development. Again, standardization in apps writing may be a limitation for someone. The most important thing is that the blocks we build with are not so much standard as versatile. This way we could write the software that suits our needs. If we impose such a limitation a level up – where we can install these apps – it’s possible that things might not work out the way we would want them to and it might not be that easy. But I’m keeping my fingers crossed because it sounds awesome.
Piotr:
It would certainly be an interesting solution for programmers, who could spread their wings not only when working in large teams, but also while sitting at home in the evening, during a break in Counter Strike or some other entertaining activity. On the other hand, what else could be an indicator for SDN development in the coming years? Are there any other elements that will perhaps cause a change of development direction? Or will we come to a dead end and suddenly realise that we have to devise a whole new approach?
Rafał:
This may be controversial, but I am afraid that eventually we will reach a point when the solution becomes so open and versatile that eventually companies will start locking it into some kind of packages, because not every operator or user will be able to write it on their own. Well, it is not that I dread it, because it is also inevitable. When you run a business and you have a website, you can either employ your own software developers, people who manage it, or you can outsource it. And that’s probably the kind of stuff that’s going to come up here. The question is whether the industry will simply arrive at the conclusion that something like this definitely makes sense. I believe this is highly unlikely. But that’s what I would personally fear the most.
Piotr:
What you’ve said is interesting because, in fact, similar situations are already taking place in other segments, e.g. operating system segments, where in fact the big manufacturers of all solutions, phones, etc., stop using the publicly available systems and create their own software to lock it down. They do it for safety reasons as well – they wish to know the ins and outs of the system. The same goes for the Internet; it provides you with access to basically everything, but it also comes with certain risks. Maybe this is the trend you just mentioned: openness and versatility is starting to be not only an opportunity but also a certain threat to the whole system.
Rafał:
Yes. Or this will be limited to a few options. The question is whether such broad programmability is required everywhere, or is it really necessary to figure everything out on our own. Maybe what we really want is the choice to automate something and write it by ourselves, should we wish to do so – it does not mean that we want to build every solution from scratch.
Piotr:
We talked about how openness may not always be the most secure option. In terms of security, are there any trends that are available in SDNs? Are there any directions that are more extensively explored by software developers? Well, because there’s also the aspect of security, which is an important piece of the puzzle, especially as far as telecommunications is concerned.
Rafał:
Oh yeah. The primary objection against SDN is that it centralizes a function. The following is a common example: there’s one controller; if we damage it in some way, it’s a Single Point of Failure. The entire thing depends on how we look at something centralized. Something can be logically centralized, while in reality it is distributed. So in this case I wouldn’t worry about that. No problem here. However, when it comes to some security applications, one of the most frequently discussed topics is anti-DDoS, because by programming all these devices on our own, we can direct this traffic any way we want. We have great room for improvement to detect and respond to these threats quickly enough. This is much more difficult in standard networks.
Piotr:
How will this translate into practice? Does it mean that there is a device, which is a system running on some hardware, that simply analyses the traffic by itself and somewhere along the way there is a filter, which already begins to filter the erroneous traffic at the device stage? This is interesting.
Rafał:
There are other technologies that support SDN. It is very common to refer to “SDN/NFV” (meaning Network Functions Virtualization). These are the kinds of technologies that allow network functionality to be virtualized, detached from hardware, and installed as applications. These applications include various firewalls and similar solutions. A traffic analyser can also perform a network function. The key property of SDN is that if we combine these two technologies, SDN and NFV, we are able to at least put a virtualized network function very close to this device. Or even on the device, so that the traffic that is suspicious to us (or all traffic) can be uploaded to an application that is already on the device, or very close to it, in some cloud, and based on that we can make the relevant decisions very quickly. It’s not like we have to send that traffic or any samples to some central point in the network. We can work on the whole traffic or on some part of it.
Piotr:
So assuming that the network is nevertheless such a mash, a system of interconnected points, do you mean that the network itself will perform the function of an anti-DDoS system? Each of these connecting elements could take over some amount of control, some mechanism or some aspect of the operation of such a security system.
Rafał:
Let us assume that this will be the case for the user. Of course, the software developer who is going to write this will separate the network and SDN from what he has implemented. He will approach it in a more accurate way. But if you look at it as a black box, then the network, the software, the applications that we’ve written, and the question whether we’re going to add other applications, is still more of a software than hardware issue.
Piotr:
Does SDN have limits? Does SDN have this glass ceiling? Once we reach it – or at least with SDN as we understand it now – we will have to turn back? Do you see any such limitations?
Rafał:
Does software have limits? Because I would look at it this way: SDN development is almost parallel to software development. And those trends that are present in network software automatically find their way to the environments that are popularizing SDN. That is, for example, monolithic applications that used to be popular in the past; drivers were created as monoliths, as a big application that has many modules. This has its pros and cons. The deployment of cloud services has been very trendy lately. With that comes such a thing as cloud native. That is, applications that are native, can be deployed in some cloud – public or private. It turns out that this trend has emerged in our SDN as well. That is, one could say that as long as software is now being developed, we will continue to see innovations in the networking domain. That is, in software-defined networks.
Piotr:
I would like to close with a question that may be a little unusual. Do you think that just like any technology, SDN will also eventually become outdated? What will happen in 5, 10, 15 years? Is it going to be an important philosophy and a major change, the revolution that we talked about at the very beginning, that it’s going to continue anyway, whether it is under the name SDN or any other name, but primarily in terms of this new approach to networks as such?
Rafał:
It seems to me that the word SDN may be forgotten in a while; this is because the very word may be interpreted as a truism. Today we like to approach things from the software perspective: it is soft (as the word indicates), much easier to develop, change and adapt. Even with old solutions. This is something we can do. Whereas in the case of hardware… the matters become more complicated. That is why soon everything might become obvious.
Piotr:
So, SDN (in one form or another) will remain relevant for both telecommunications companies and for the development of the broadly understood telecommunications equipment, regardless of the name under which it will appear.
Rafał:
I think so.
Piotr:
Rafał, thank you so much for the interview and for your time. Our guest was Rafał Szwedowski, SDN Architect at EXATEL. See you at the next opportunity!
Rafał:
See you!
