A technical mastery of the telecom industry and its networks can never be fully achieved: there are just too many knowledge domains, too many changes, and too little time. The best we can hope for is to master our particular niche and retain a partial knowledge of the bigger picture.
The conference speakers at the recent Dallas MEF event I attended were outstanding. Sure, many of the acronyms and concepts discussed at the sessions flew over my head, but soaking my brain at the conference in the new technical vocabulary of NFV/SDN did me some good. And it certainly pointed me to areas of knowledge I needed to explore further.
Trouble is, web searches are generally not as productive as they could be. The deep details of NFV/SDN knowledge are just not available on Wikipedia. And on vendor sites, it’s often hard to separate fact from hype.
Fortunately there are some experts out there who understand the key issues and can explain NFV/SDN concepts to network laymen like myself. Luckily I ran into two very bright guys, Marcin Paszkiewicz, CEO and Bartosz Michalik, Technical Architect of Amartus, one of the premiere technical shops who help Tier 1 and Tier 2 carriers build multi-vendor networks.
In the conversation below, Marcin and Bartosz give us a tutorial on how NFV/SDN comes together, especially in terms of large scale multi-vendor networks. Along the way, they clarify the significance of key development standards like OpenDaylight and key implementation challenges the industry must overcome.
Dan Baker:Bartosz, sounds like the SDN and NFV standards are merely the starting point for implementing these virtual networks.
Bartosz Michalik: I agree, Dan. Of course, when it comes to SDN, the southbound is well defined — and that’s Open Flow. Similarly, existing NFV solutions conform to a reference architecture from ETSI. Using these specifications as our base, we (the community) have created many excellent open source and commercial software which drive existing networks, clouds and data centers around the globe.
But it’s very true that other standards are needed. One of the latest initiatives of MEF is to define LSO (Lifecycle Service Orchestration) specifications that allow for orchestration of services among multiple operators, providers and subscribers. So the interfaces to support horizontal communications also await standards.
One of the projects important to your work is OpenDaylight or ODL [logo pictured above]. What role does ODL play in the SDN movement?
Bartosz Michalik: The OpenDaylight (ODL) project is a shared effort to deliver an SDN (and NFV) open platform. It is an open-source project and quickly growing ecosystem. Some solutions built in the platform have become de facto industry standards.
The big benefit of ODL is deliver a consistent interface or “whole world view” for multi-vendor management. This includes consistent communication and event handling over various protocols, and a consistent, up-to-date data model of all devices under ODL control.
There are many ODL use cases and commercial implementations. However, for me ODL is a project that makes the evolutionary transition toward SDN easy. ODL architecture enable multiple southbound drivers that can “talk” to devices using SNMP, Netconf, OpenFlow, while maintaining consistent “whole world” view on managed network.
Therefore, ODL platform allows for multi-vendor solutions or seamless migration toward OpenFlow based switches.
Are there other platforms that compete with ODL?
Bartosz Michalik: Yes, ODL is not the only open source project that receives a lot of industrial attention and contribution. Another good example of multi-organization collaboration is ONOS. ODL is generally focused on bringing legacy functionality to the platform (BGP, SNMP etc.) and marrying that with new technologies such as OpenFlow. ONOS, meanwhile, focuses on performance issues. But there are other open source projects around SDN too. We should not forget about Ryu, Floodlight, OpenContrail, Beacon or POX/NOX.
All the SDN controllers differ by their technical stack, number of features they support, and community support. ODL and ONOS stand out because they are projects with deep industry attention and a well developed ecosystem. Therefore, one of those two should definitely be your first choice when you evaluate open-source options for SDN controllers.
Bartosz, I noticed a lot of discussion at the MEF conference around the Hackathon at the event. Did Amartus participate in that? What’s the value of these Hackathons?
Bartosz Michalik: Yes, I was pleased to participate in the first LSO Hackathon organized by MEF — it was a highly collaborative event. The mission was to build solutions that utilized LSO APIs on top of various SDN controllers.
These Hackathons deliver great benefits. First, they draw attention to the LSO initiative. Second, they provide a lab where LSO APIs can be examined in practice by many software and network experts. Finally, everything developed at the Hackathon is donated back to the community. For more details, I recommend reading a short blog post about the Hackathon event.
What are some of the technical bottlenecks or challenging areas that must be overcome to speed adoption of SDN/NFV in multi-vendor networks?
Bartosz Michalik: Assuming the standardization takes hold, we should end up with several classes of compatible devices or/and software components. Regrettably though, I don’t expect to have it happen soon. Therefore, running a hybrid solution (with its services migration related issues) will be a key challenge in the next several years.
Another challenge is there are many use cases that come with SDN/NFV. And we are not only looking for solutions that are more maintainable and more accessible to the customers, we also want fast delivery and the ability to give partial control over the network to the end users.
In my view, the biggest obstacle we face in moving to the new era is maintaining the same level of performance, security, and availability we have with current networks.
How fast will virtual telecom networks roll out in your opinion?
Marcin Paszkiewicz: A few years ago I heard that the time span for SDN adoption would be about 5 years. Last year I heard the same prediction :)
NFV/SDN solutions are and will be gradually adopted. Often the technical solutions precede actual standards. That’s been the case with NFV infrastructure (NFVi).
In my opinion we will never reach 100% adoption because it’s simply not needed.
Performance is key to successful SDN/NFV solution so I expect we will have a lot of work in this area. But I expect we will have less of the typical integration work we do today. In five years we will still be running multi-vendor solutions. SDN or NFV components will simply be other building block types to integrate.
I understand you have an example use case at a Tier 1 operator.
Marcin Paszkiewicz: Yes, Dan. As you know, big service provider networks consist of heterogeneous equipment (different versions, features, vendors). Now since the trend is to deliver network services quickly with a high level of automation, a multi-vendor solution becomes a management must.
So one of the most important use cases we’ve completed was to enable a Tier 1 customer to offer MEF services on top of a heterogeneous network. Amartus developers were responsible for mediation of MEF QoS settings to vendor specific QoS settings and building a northbound API to expose MEF compliant QoS settings.
Now there are several ways to support multi-vendor applications. One possibility is to use a single NMS to manage the whole network. Another approach is to use several NMS systems to manage specific device types and then have an orchestrator on top.
In this particular case, we helped the Tier 1 operator uses its own orchestrator to deliver the service that spans across equipment from multiple vendors.
In this project, as in many others, you used the REST interface. I also know that you have extensive experience with the YANG model. Why are these standards useful?
Bartosz Michalik: REST is just a very common and easy communication paradigm. Its beauty is that it’s technology independent — the data payload is transferred in XML or JSON format. REST has a very good implementation for most of the programming languages that ease the development and is well understood by developers. And since it is carried over HTTP, there is no extra setup/configuration needed to communicate via REST.
Now YANG is a data modeling language and can be used to model any domain. YANG was developed as a result of rapid adoption of NETCONF. We used YANG in another project that we led because our customer required the ability to communicate via protocols that define payloads in YANG.
Some YANG features that make the language useful are: hierarchical structure of data, reusable data types, augmentation mechanisms, support for RPC definitions, formal constraints, versioning, and modularity.
YANG usage goes beyond a definition schema for NETCONF. YANG is often used to design domain models (e.g. in ODL or NCS) and those models are later used to generate code (model driven approach to system development).
Tools developed by Amartus allow customer to generate RESTCONF (NETCONF over REST) interfaces from any model defined in YANG and automated mediation to the customer data models. In other words, using the developed tools, we can automatically expose any customer model via RESTCONF — no manual code is needed.
Thank you for clearing away some of the cobwebs around multi-vendor NFV/SDN networks. Please tell us where carriers and network equipment providers (NEPs) need help in moving to these new world solutions? And how does Amartus engage with its clients?
Marcin Paszkiewicz: Well, NEPs are cutting edge device experts. Carriers, meanwhile, are in the business of providing services that ride of NEP devices. So Amartus bridges that gap. We ensure carriers are able to use these devices in their complex infrastructures.
We have about 50 mostly senior and architect-level software and network engineers in the company. And we get hired because we know more about building software than networking experts, and we know much more about networking than your average software engineer. So our understanding of those very different worlds enables us to deliver end-to-end solutions for our customers.
During the last twelve years on the market we have worked with devices coming from all major NEPs. A key strength of ours is illustrated by the case study I just talked about: the ability to provide software that automates communication in multi-vendor infrastructures. That’s a key requirement for all forward-looking carriers.
This article was originally published by Black Swan and has been reproduced with their permission.