This week, we implemented new features in our Flow Manager product that allow large network providers to immediately evolve their BGP/MPLS networks toward SDN, using a centralized controller and lower cost infrastructure. We will be demonstrating these features at the Linux Foundation’s Open Networking Summit in Los Angeles.
SD-Core brings both existing BGP/MPLS routers and new white box switches, under the control of SDN, combining the use of BGP, PCEP, NETCONF, OpenFlow and P4, to deliver automated end-to-end services, provisioning and management.
“In every SDN deployment, bringing the existing network under an automation framework is the number one priority,” said our CEO, Andrew Coward. “What makes Lumina different, is our ability to operate a single control plane that software defines the existing routed network and enables white-box vendors to integrate into the solution with next-generation switching protocols. This allows our provider customers to offer their existing services seamlessly over both, while at the same time expanding their offers to more advanced services, thus bridging the gap between the old and new”.
Our Flow Manager now supports the ability to define VLAN, MPLS and Segment Routing intent paths over low-cost switches. Also, Flow Manager can assign packet transport services to the paths including E-Line, E-Tree, L2VPN or L3VPN. To achieve these capabilities, Flow Manager runs using the Lumina SDN Controller, Powered by OpenDaylight™, along with the OpenFlow and BGP plugins provided by the controller.
The implementation includes a centralized path policy manager function providing many of the traffic management features found in traditional BGP/MPLS networks also provides very unique features including fine grained traffic classification at the service ingress node, traffic replication and point to multi-point (P2MP) services including “anycast” destinations, and L2-L4 packet field manipulation at the service egress node.
Lumina Flow Manager release 6.1 is available as a free trial version, along with the Lumina SDN Controller, Powered by OpenDaylight™ and can be obtained athttps://www.luminanetworks.com
Network functions virtualization is on the rise, but not in the way that many thought. TelecomTV sat down with several industry leaders to discuss the future of NFV and SDN, and the role it will play in business technology and transformation in the years to come.
Lumina doesn’t believe in selling turnkey solutions, but also doesn’t believe in leaving the introduction and integration of its products to the CSP. We believe that we can serve as the catalyst for a company’s digital transformation initiatives, helping out on the heavy lifting while teaching our customers how to manage their network from the core to the edge and think outside the (hardware) box. By working closing with a CSP’s internal NetDev team to give them the tools they need to succeed, we set them up to win the long-term process of transformation without sacrificing short-term gains.
“[We] soon came to realize that our market could be divided into early adopters and laggards. CSPs’ likely willingness (or not) to engage properly in this way could be gauged by how diligently they approached things like a [request for proposal],” he says. “We found this created a self-selection process for us because the ones that asked the right questions were more receptive to us and more willing to “play catch” with some of the open source projects.”
However some went the other way, saying “We don’t need any help, we’re going to do everything ourselves and manage everything. But inevitably some of those customers found it was a Herculean task to do all the integration, manage the new open source code, compile it, keep it reliable and keep up with the changes.”
So some of those companies that had originally struck out on their own subsequently had a change of strategy and came back saying, “You know what, it doesn’t make sense for us to manage the relationship with open source or adding new features when you guys can do that.”
That turned out to be a viable business model for Lumina. “On one level we help with the integration, but what we really do is provide abstraction,” claims Andrew. “With SDN we’re trying to separate the business logic of the carrier – which defines the services – from the underlying hardware and from the vendors […].
“The great thing is that everything that gets built gets put back into the community and makes the job much easier the next time around.”
The abstraction layer also hopefully avoids the CSP customer accruing what’s known as ‘technical debt’. That occurs when devices are integrated directly or tactically (without an abstraction layer) creating a debt that will have to be paid back with interest in integration difficulties later.
“Five years ago we didn’t comprehend the need for CSP culture change to enable transformation,” says Andrew. “But things have changed greatly with SDNFV over the past four years especially. The industry has had to move from a science project through to ‘available in the lab’ and then to something that could be deployable. In the great scheme of things I think we’ve moved remarkably quickly on the open source side of things to make that happen.”
Most importantly it’s turned out that the industry wasn’t – as it perhaps at first thought – introducing a new technical framework and, ‘Oh by the way, you might have to change how you do things a little’. It now looks as though we’re introducing new ways of engaging with customers software, services and suppliers with some necessary and useful technology coming along for the ride. Culture change in other words, has become the prize, not the price.
There’s no doubt the process has been slower than thought. Why?
Andrew thinks “a lot of stuff got stuck in the labs and there was a feeling that everything had to be new.” In too many cases that appeared to mean white boxes needed to replace legacy hardware and there was a feeling that “before we can adopt this technology we need to put data centres in,” Andrew maintains.
“Actually, on the SDN side it’s predominantly all about the existing equipment. So not about replacing, but making the ‘physical’ equipment work with the new virtual environment,” he says.
Another reason software might stay in the lab might be a pervasive fear of ‘failure’ on the part of many CSPs, somewhat at odds with the IT “fail fast” credo. Allied to this can be a reluctance to upgrade the network – in sharp contrast to the constant upgrading undertaken by the hyperscale players many carriers would like to emulate.
Overcoming the upgrade phobia would help the new software ‘escape the lab’ on a more timely basis says Andrew.
“We’re looking for customers who have captured this technology and understand what it is they want to do. Typically they have stuff in the labs and they now want to get it out and they need a partner to help them do that. They don’t want to hand the task off to an outsourcing company because they’ll lose the learnings that they have and they won’t be in control of the outcomes. So they want to keep doing it but they know they need some expertise to help them with that process.”
Lumina Networks is proud to be a partner for the Linux Foundation. We will be exhibiting our industry-leading SD Controller at the Open Networking Summit next week in Los Angeles, and look forward to meeting with attendees to help them learn how to get the most out of the network and start on the path toward full digital transformation and business digitization.
ADVA Optical Networking will host a joint demo with BT at Mobile World Congress that showcases end-to-end, multi-layer transport network slicing and assurance. We’re particularly delighted to see this illustration of how edge computing and network slicing techniques can enable emerging 5G applications as it is in part made possible by our technology. With the growing anticipation of 5G connectivity, there is a critical need to develop a new transport networking technology that can meet the cost, efficiency and flexibility requirements. This demo marks just the first step in a long-term research collaboration between ourselves, ADVA, BT and other partners in this emerging space.
If you’re attending Mobile World Congress and would like to see a network architecture optimized for a new generation of applications that will enable enhanced mobile broadband, self-driving cars and massive IoT, stop by Hall 7 Stand 7H31 or Stand 7020MR.
“5G is set to enable use cases that go way beyond mobile broadband. By showcasing transport network slicing within an SDN-controlled infrastructure, we’re paving the way for 5G to support different use cases on a common infrastructure that could enable anything from self-driving cars to the massive machine-type communication (mMTC) needed for billions of IoT devices.
“Our demo shows that true end-to-end network slicing is ready for deployment. That means multiple network allocations using the same physical infrastructure can be delivered in parallel, not only in the radio access network (RAN) and mobile core network but also across transport and infrastructure resources. This technology will be vital for generating the flexibility and agility needed to bring incredible 5G applications to life,” said Anthony Magee, director, business development, ADVA.
Maria Cuevas, head, mobile core network research, BT, said, “By showcasing an architecture for wholesale services that can be efficiently reconfigured across all network layers through SDN control, we’re taking a big step forward. But this demonstration is really just the start of an intense period of research into network slicing. Our close collaboration with ADVA and other partners in this space will help us optimize our network for 5G and harness the technology’s potential to shape the future.”
During our recent webinar hosted by SDxCentral on SD-Core, we took a survey of interest on SD-Core and polled the audience on some of their preferences in where SD-Core will be applied. What is the definition of SD-Core? SD-Core is the term for the set of use cases that involve the evolution of core network technologies, such as MPLS, toward software defined networking. SD-Core is very different from SD-WAN, in that it pertains to the architecture of the service provider’s internal core network.
The term SD-Core is being coined because we at Lumina Networks are seeing the service providers looking to rapidly evolve their core networks and we are involved in several initiatives at major service providers globally. These initiatives involve both PoCs and deployments of various stages. Developments such as SD-WAN, 5G and others are putting pressure on the core networks not just in terms of traffic load, but also in terms of the need for service agility. Most of the market research I’ve seen says that carriers as a group are spending between 3 and 5 Billion dollars (US) per year on core network enhancements.
Our webinar attendees were admittedly parties interested in the SD-Core in the first place, but it’s still interesting to look at the poll results between the various options.
When asked, “if you are planning to evolve your MPLS core-based services, what underlying technologies are you considering?”, the audience was conservative.
The clear winner was adding central control to the existing network. I would interpret that to mean a desire for improved service agility and automation for the existing infrastructure. This also reflects our business at Lumina Networks as much of our NetDev activity centers on adding SDN control capabilities to already-installed switches and routers. Running in close second were the set of protocols that would involve changes to the underlying infrastructure including the desire for whiteboxes, OpenFlow or the very latest technology, P4.
So, for the next question, “what services are you looking to evolve to an SDN-based core network?” The results are not a surprise.
At a glance, this data likely reflects the service that network engineers administer today.
At Lumina Networks, we believe that core networking is ripe for a disruption. Emerging data plane technologies along with advances in open-source-based orchestration and control software are too compelling for service providers to keep doing things the old way. The question will be in how service providers transition their networks to the new technologies while maintaining their core network services. We’ll have more on hybrid core networking in a future Blog. Stay tuned to Lumina Networks!
Getting started as an upstream contributor to OpenDaylight is not easy. The controller ecosystem is big, there are many projects, and there are millions of lines of code. What is a new ODL developer to do? Here is some pragmatic advice on where to begin to become an active contributor.
One of the easiest ways to get to know a code base is to start fixing bugs. Peruse the ODL bugs list on Bugzilla, say with the NETCONF project. You want to find bugs that aren’t likely being worked on and are of limited scope (to match your limited understanding of the project). Ideally bugs will have an owner assigned to indicate that they are actively being worked on, but it is not always a great indicator. In particular, someone may run across a bug, file a report, then jump into fixing it—and forget to assign it to themselves. This is most likely with the project contributors, so figure out who are the project contributors and look at the date of the report. If it was a project contributor and a newish date, then that bug might be being worked on. You should read through the report and try to decide how much domain knowledge is needed—as a newbie, smaller is better.
Once you have selected a bug to work on, click on the “take” link. Also add a comment to the bug. If someone already is working on it, they should get a notice and respond. You can also try the ODL mailing lists and give notice there. You mainly want to avoid duplicate work, of course.
Reviewing patches is a great way to contribute. You can access patches via Gerrit, and we’ll use the NETCONF patches as an example. Doing code reviews is a great way to not only see existing code but also to interact with other developers.
If you have some domain expertise and know the code, you can review the functionality that is being pushed.
If you have neither of these, you can do the review based on Java best practices and good software engineering practice.
Address Technical Debt
ODL uses Sonar for analytics of the upstream project. Here is an example for the NETCONF issues. Note that the ODL project has coding conventions, and the Sonar Qube has some best practices. This list shows violations that should be addressed. As a newbie, you can work on these with little domain knowledge required. You can also see that the code coverage varies for the NETCONF coverage, so adding NETCONF unit tests to boost the coverage in the weakest areas would be very helpful.
Sonar has a lot of interesting metrics. You can explore some of them starting here including coverage, tech debt, etc. If you look at the Sonar dashboard, it will point out a lot of available work that does not require a large span of time to invest. Doing some of this work is a great step towards getting your first patch submitted.
Follow Best Practices
With well over a million lines of code and many contributors from many companies, the ODL project has quite a girth. To manage the code entropy, ODL has some best practices that you should become familiar with. These cover a diverse set of topics, including coding practices, debugging, project setup and workflow. We strongly recommend that you carefully read these. They will save you a lot of time and will pay back your investment quickly. They will help you skate through code reviews. These practices are really time-tested advice from all the ODL developers, so don’t ignore them.
Attribution is an important insight into most if not all open source projects. Attribution allows stakeholders to see who is contributing what, from the individual up through sponsoring companies. It allows both a historical and current view of the project. You can see an example of why attribution is illuminating here. You need to sign up for an ODL account, and a part of that process will be to associate yourself with a company (if applicable). You can also see breakdowns by authors on the ODL Spectrometer.
That’s all for now. Happy trails, newbie.
Watch for Allan’s blog next week where he will share his Top 10 learnings as a new developer contributing to ODL.