Thank you for standing by, welcome to the Arm and Networking Software conference call. At this time, all participants are muted, but if you require operator assistance, please press star and zero on your telephone keypad at any time. I must advise you, the conference is being recorded on Tuesday, the 8th of September, 2015. Now, I would like to hand the conference over to Philip Sparkes. Please go ahead, sir.
Thank you very much, thank you everyone for joining our call this afternoon. I'm Phil Sparkes from Arm's investor relations team, and I'm joined today by Robb Monkman, enterprise segment marketing manager, and Jérôme Ramel, technology analyst from Exane BNP. Today, Robb and Jérôme are going to discuss the role that open-source software will play in next generation networks and Arm's role in the open-source community. This will be a listen-only call, if you have any specific questions you would like answered during the call, please email them to investor.relations@arm.com. If we don't get a chance to answer your call today, we will follow up with you afterwards. If you would like to learn more about this topic after the call, you can view Robb's online webcast, which is currently available on our website, investors.arm.com. Without further ado, I will hand over to Jérôme.
Thank you, Phil. Good morning and good afternoon. Good morning, Robb. Before digging into Arm's role in open-source software, maybe we could spend some time to talk about the role of open-source software. To start with, Robb, what do you think will be the implication of the migration to software-defined networks and network virtualized function? Maybe at the hardware level, will the re-architecture of the network with putting more intelligence into the network versus at the end of the network lead to more standard hardware equipment as opposed to highly optimized hardware? How do you see the trend?
Thanks, Jérôme. I think we absolutely see the Arm ecosystem actually quite uniquely positioned to provide a pretty compelling value proposition to both the network operators and their equipment suppliers when more intelligence is pushed deeper into the network. This is really the fundamental concept of what we call the intelligent, flexible cloud. Really what's behind that is the applications for network infrastructure intelligence are very highly, a range of various kinds of use cases. They require different combinations of compute, storage, IO, network processing, packet processing, and also acceleration in all of those areas. There really is no one size fits all in sort of the big CPU plus a NIC over a PCI bridge that works well for PC workstations and vanilla servers, doesn't always map well to all of the use cases in networking infrastructure.
What we see is that it's precisely this, the range of highly integrated and workload-optimized SoCs that's modeled by the Arm ecosystem that's needed in this range of problem sets or use cases, if that makes sense.
Yeah. Okay. At a software level, will the SDN and NFV lead to a more crucial role played by the software rather than hardware? Will the software be the key element in getting more flexible, automated, and networked, and how will it work?
Yeah. Software will absolutely play a much bigger role than ever, and yes, I think increasingly a more crucial role than hardware itself. It's rather subjective as to how it tips that balance. What I see is the software relevance, moving forward, is primarily going to manifest itself in three areas. Number one, management and orchestration to automate and increase the efficiency of the network functions themselves. Number two, with SDN and NFV, what you see is there's a network virtualization layer. That is to say, an abstraction of the management policy and control plane from the forwarding or data plane. The forwarding and data plane is where all of the packets actually get routed, get identified, classified, and that's where all the high throughput and low latency is required.
There's a great deal of innovation that needs an experimentation that is happening in this network virtualization layer. It's also where already there's a realization that it's not going to be quite as easy to use as is all of the new virtualization technologies in communications infrastructure. Because again, I noted that in this space, when you're talking about quality of experience of connected devices and people wanting to watch video and this sort of thing, you need very low latency, very low jitter or variance, very high data rates, and it's far more demanding than a typical corporate enterprise network. They're already seeing, we're already sort of entering what sometimes is called the trough of disillusionment, and what that means is, wow, this is not working quite as well as we thought it was.
It's not transferring as easily, we're going to need to do a lot more work in this network virtualization layer. Thirdly, the other big area that I see software playing a big role is in what I call, and others call, the service enablement layer. This is really where there's going to be a lot of innovation done by the operators themselves, or they're either going to acquire it or they're going to develop it in-house, and it's going to be separate from the underlying open source NFV platform. This is where really you have a framework for launching and executing subscription-based services to compete with the over-the-top players. I think we can drill into that a little bit later in our conversation. Those are the three areas that I think that software's going to play a big role in.
I do want to emphasize that, again, when you talk about the high demands of this space, the hardware still matters and the acceleration still matters, particularly when you're trying to abstract and virtualize, because that in itself, while it makes it easier to logically manage and orchestrate a network and provision a network, it also adds overhead. Everyone that we see in the Open Platform for NFV umbrella project, for example, is agreeing that acceleration is going to be needed and optimized hardware will be required. It is in fact the case that the hardware will be packaged and managed much more in a standard way, I would say.
Yes. Thank you, Robb. Actually, that was one of the question I wanted to ask you is, how will software help telecom operator achieving the end game, which for them is generating more revenues and not being just a dumb pipe supplier with all margin being done by the OTT as you mentioned, I mean, such as Skype, Netflix, WhatsApp?
This is what it's all about, right? The move to SDN and NFV, there's several aspects to it. There is an idea that they may have some CapEx savings that's already being questioned. There certainly will be some OpEx savings, more standardized, having more standardized management and orchestration will make it, and everything more common and interoperable. That will lower the cost of interoperability. The fact is, the OTT players do not have the cost of running the network, they've got to have revenue equation as well, right? I mentioned earlier that one of the big software areas will be this service enablement layer, and that's the ability to create and launch very quickly new, innovative services that they can then compete directly with the OTT players.
I'm hesitant to kind of use this term, but there's a term getting bandied about, sort of network app store, and I use it cautiously because networks are not consumer devices and the apps and the services that our people or the operators will run are much more niche and more sophisticated than broad. You're not going to run Flappy Potato on the network, right?
Yeah.
That's the concept, though. It is a common framework, that they either develop in-house or they partner with some specialized provider to create the ability to provision, launch, execute, and manage these services and sell those services to their customers and derive revenue. This requires a pretty big software investment that's already been going on in the research groups within operators. In fact, there's already been some evolution in deployment. This is where it's all going to happen, and it's going to fit on top of the open source platform for NFV, for example. This is what they're going to use to drive loyalty, to drive subscription revenue.
Okay. If the networking equipment world is moving more to a standardized software approach, why should this favor Arm customers who are building system on chip with specialized accelerators? Why does it not favor traditional server vendors?
That's a great question. Really, this is quite different. I mean, when we look at the communications infrastructure marketplace, it doesn't favor Arm, and it doesn't necessarily favor Intel either. The fact of the matter is, really, all of this new open source platform development software that's being done by the entire supply chain, the operators, the equipment providers, ISVs, the silicon vendors, a lot of it is brand new, and it's not even ready for prime time yet. It's not the same software, in other words, that's used in the cloud data center. I mean, OpenStack itself is an example that many people may have heard of. That's going to have crossover. OpenStack is very new, and it still doesn't do very much. A lot is going to be added in the way of plug-ins and extensions for networking.
Then you have pieces like OpenDaylight and Open vSwitch and KVM and so forth. Many of these pieces are brand new, and in fact, one of the projects that I point to in this space Is this, I've mentioned it before, it's called OPNFV and it's run by the Linux Foundation, and it is a collaborative project, and the entire supply chain is working together to begin to improve these upstream projects, OpenStack, OpenDaylight, KVM, Open vSwitch, et cetera, and integrate them together, because individually they're all kind of working on their own functionality, but OPNFV is about integration. This project, their second release is not until February of next year, and that's only characterized as a lab-ready release. Deployment isn't even a consideration until the end of the year 2016.
It's a really level playing field because much of this software, as I said, is still in development, still evolving, still being hardened and fleshed out. That levels the playing field and we've been engaged in that project since October of last year, when we get to the deployment timeframe, it's going to be parity and we're not going to be at a disadvantage. There's no inherent, all the software is available to everybody, right? Whoever puts resources on it and whoever optimizes it on the individual platforms will then have strong deployment solutions to win designs.
Understood. Now, Robb, looking at the impact on software, Arm is obviously a strong believer in the open source software. My question is, what makes you confident this is a trend the industry will endorse? You explain in your presentation the advantage of using open source software such as interoperability, faster time to market, or even security. Aren't there any disadvantage? The pushback I'm hearing sometimes is that the developing solution will be more in line with the developer wish rather than customers.
Yeah, I think there's always that risk that individual developers can go off the rails a bit and work on adding things that they think are really needed. I think when I very specifically look again at very coordinated and organized efforts like the Open Platform for NFV, the operators are absolutely mandating that they want to see open source solutions. They're driving it and no one has really questioned that. Certainly we're going to see certain players who will try and, because of the fact that they have a lot of developers and they have been baking some concepts in-house, will try and influence the direction of the project. There's both good and bad here, right?
One of the disadvantages of open source is that if you just have an ad hoc distributed development with no sort of organization, no steering, no road mapping, then it can be a bit chaotic, right? Open Platform for NFV is a structured project. It has a steering committee, it has a strategic committee, both of which I sit on. We debate, we consider, we carefully manage the overall direction and roadmap of the project. That gives it a sort of, let's say, a bit of adult supervision, if you will, to ensure that the project doesn't go off the rails and we're working towards real-world hardened deployable solutions. Again, it is possible to talk about your other concern about, say, one of the big vendors just dumping a bunch of their code into the project.
Sometimes that can happen, and that has happened in the past. I think generally speaking, if the community is strong, they will push back on that and that will get revised and done in a slightly different way. There's no doubt that in the end, when you have strong participation from a wide range of stakeholders, if the code is good, and I've seen this happen before, there was pushback. One vendor provided a base framework, but in the end, the code was quite good and people could not argue against that. When more people started to look at it and contribute to it and work with it, they got over that and it ended up being, it's actually become one of the key projects in OPNFV, for example.
Generally speaking, that can be mitigated, because it has to stand up to the peer review of the people who have to make this stuff all work in the end.
Yeah. Very clear. Understood. Maybe, Robb, moving to Linaro. In your presentation, you described the way Linaro operates and its mission. Placing Linaro in the entire software jungle ecosystem, because there are so many things going on, I'm just curious to know how should we think about Linaro versus other initiatives? On slide 12 of your presentation, you mentioned some of the most popular open source projects such as OpenStack, OpenDaylight, OpenFlow, OpenDataPlane. Is Linaro competing to this project, or is it complementary, and if so, how?
Oh, absolutely, Linaro is complementary. The way that it works is, generally speaking, Linaro is not creating new open-source building blocks necessarily. What their primary goal in life is to unify the Arm ecosystem and work on the existing relevant and important, as judged by its members, the important existing open source components as they are today, and improving them, validating them, porting them, and optimizing them for the Arm ecosystem. They generally never compete with another individual open source project. These open source projects that we're talking about, such as OpenStack and OpenDaylight, are very focused projects that work in a certain area. In fact, this is the same thing really that OPNFV is doing. OPNFV is an umbrella integration project. It's just integrating those components, piecing them together, filling gaps. Linaro is really doing a similar, contributing that same kind of effort.
Linaro is also a member of Linux Foundation, and they also participate in OPNFV. It's really just making sure that the Arm ecosystem has solid support for all of these pieces, and stitching them together and making them work. There's no competition there. Now, OpenDataPlane itself is a bit unique because Linaro actually did create that project. They created it because there was no cross-industry recognized standard for interfacing to the data plane for a wide range of instruction set architectures and a wide range of different hardware approaches, whether it be FPGA or network processors or plug-in NIC cards. OpenDataPlane was something that Linaro created from scratch and actually has made its way into the OPNFV community as a recognized and important initiative.
Sometimes they do create something new if it doesn't exist and it's a problem that needs to be solved.
Thanks. I will have a little bit more question on OpenDataPlane, but before that, looking at the different project we mentioned before, it seems that OpenStack in cloud seem to have received a strong endorsement from industry players, but it's still not the case for OpenDaylight, for instance, or even OpenDataPlane. I'm just trying to understand what is missing at this stage to see a strong endorsement?
Well, first of all, I think OpenStack is a management framework, you're correct. It definitely has received a great deal of attention and endorsement as one of the better potential approaches to creating a management solution. You have to fill in plug-ins, you have to add policy above it then put plug-ins below it and add things for it to do. It doesn't do anything in and of itself. It's a framework for management, it always has to be customized. It has been well customized for cloud. It's not yet fully fleshed out for network infrastructure, but that is going on. I think that because it's more general, there are more people who are interested in, who are stakeholders in it gets more attention.
OpenDaylight, for example, it's very much focused on the network controller, the controller layer of software-defined network concepts. It's much more niche. There's fewer developers that understand that, it's an area of greater debate. In fact, there's a couple of three camps that we see out there, that are looking at different alternatives to OpenDaylight. OpenDaylight actually got off to a bit of a rough start, but it has actually made quite a bit of momentum in the last year or more. It is now part of the standard stack and plays a crucial role in OPNFV's Arno release, which was the first release they did in May of this year. It still is the primary SDN controller for the B release, the second release coming in the spring of 2016. It has made progress.
Again, I think it's related to how specialized it is, it's the same really with OpenDataPlane. OpenDataPlane is also very new, it's even lower level and more niche, more specialized. It's really right on top of the hardware, there's fewer stakeholders that need to or want to care about that level. Those who do, so the network stack people, the virtualization layer people, anyone who wants to interface directly to hardware, they will care about that. That's a much smaller community. I think with respect to OpenDataPlane, it's really been incubated by a very core set of people who care about that, we're just getting to the point now where it's now becoming part of the OPNFV release, we're starting to get outside contributors to it.
More people will see it understand its value, it will start to take off. We're quite confident of that.
Yeah. Interesting. Digging a little bit into OpenDataPlane, Linaro launched an initiative in 2013 and released its ODP version one. The aim is to support software interoperability, whatever the instruction set architecture is, meaning it will be agnostic if it's run on Arm, x86, MIPS, or even PowerPC. The question I have is, does the move to open source software benefit Arm any more than those other architectures? If ODP are agnostic to the processor architecture, why semi vendors would choose Arm?
There's two questions in there, and the first one is, does open source software in the OpenDataPlane sense, in terms of providing a common interface to the underlying data plane hardware, does it advantage Arm more than others? Fundamentally, no, it doesn't. Again, it's just open source software. Keep in mind that many of the SoC vendors who helped create OpenDataPlane are just now coming out with their first Arm SoCs, but they come from the MIPS and the Power world. Today, actually, their initial implementations of OpenDataPlane are on their MIPS and Power SoCs that are still being sold every day into network design, because that's where the hardware is today. In the future, now they're developing their Arm version.
We've been quite agnostic there, I think moving forward, though, it's quite clear that the number of people who are, just because of the broad industry usage of Arm and Intel in other markets, there's just a massive software ecosystem out there for Arm and Intel. I think it'll be about how many developers, how many stakeholders there are who will contribute to OpenDataPlane longer term for all the different architectures. Clearly, I think there will be more developers, more stakeholders on Arm and x86 moving forward because really the new designs are happening there's going to be more emphasis there. Today there's actually about five or six. There's two other not-so-well-known proprietary architectures that ODP is supported on, everyone is free to contribute.
Okay.
There's a second part of that question was why would SoC vendors agree to an abstraction common software? Here's the real key, if I may, for OpenDataPlane. We made a very conscious decision early on that we would separate implementation from the API layer. It's very much in the vein of what was done with OpenGL. 15, 20 years ago, there was proprietary graphics accelerators, and everyone had their own code, their own programming interface to these graphics engines, and they created an open source common API layer in OpenGL, and then underneath, the innovation could shine, and the implementations could compete based on their capabilities, their ingenuity, and their ability to deliver. That's exactly how OpenDataPlane is done. The SoC vendors are not limited to a one-size-fits-all lowest common denominator.
The API, if they don't support something that's in the API, they can do a software implementation of it, or they can do an optimized hardware-assisted version of it. That's where the competition will occur. The point is that the software up top sees one API layer, which is great.
Could you update us on the actual achievement for SoC vendors? Is there any proof of concepts to share with us?
Yes. There are some private POCs, and there are some very public POCs. There have been some proof of concepts with OpenDataPlane done on the AMD platform. That's POC number 25 in the ETSI industry standards group. That's a virtual EPC. There's POC number 31, I think, which is a virtual set-top box that's done with Samsung and Freescale hardware and Applied Micro hardware. There has been also a service provider edge application done with Ericsson. There's been several official ones, and there's a whole number of less public ones that have been done as demos and shown at trade shows. IPsec appliances, security appliances, service function chaining. Those are really starting to proliferate now that ODP is there and the Arm hardware is coming online.
We're going to see a lot of proof points in the next 3 to 12 months of sort of modern, newer Arm SoCs with proof of concepts showing these NFV concepts, how well they can perform, and I actually think that within the next few months, we're actually going to start to see finally some benchmarks as well as functionality. Making very good progress.
Yeah, it's quite impressive because it just started two years ago, basically.
Right.
Yeah. Robb, you conclude your presentation saying that you foresee more royalties for Arm coming soon. I have a couple of questions on that point. The first one is, will Arm get any sources of revenues from software developed by Linaro?
It's not entirely out of the question in the future, but that's not the way it operates today. The point of Linaro is really to drive design wins for Arm silicon by making sure that the needed, popular, commonly required, and worked-on open source software is available and optimized for the Arm ecosystem. What happens is all of that software. Let me back up a little bit. It used to be, maybe five, eight years ago, a lot of that software, each SoC vendor did themselves. It was fragmented. People were duplicating work. It wasn't necessarily done in an interoperable way. That's what Linaro was formed to do, to stop duplicate efforts, to reduce fragmentation, and to upsource upstream, available for everybody in the Arm ecosystem, all the common work that was needed for everybody.
They could differentiate with their own specialized stacks around that and on top of that. Once that's upstreamed, typically what happens is, let's say for the tool chain and the Linux platform itself and other pieces, those are typically woven into the distributions of commercial vendors who do a business model of doing support and services around open source. This is the Red Hats and the Canonicals and the SUSEs and Wind River and Enea and so forth and so on. Those guys, our ISV partners, are the ones who will provide. The software is available to everybody, but ISVs will provide support and integration services, and they'll charge for that value add. Arm really does not get directly involved in that part of the supply chain.
We're about enablement and interoperability and positioning our partners to win more design and sooner because the software that's needed is there. When I made the comment about driving more royalties sooner, what I meant was, if we make sure that the right software is available, highly optimized, and available as soon as possible, then we'll get more design wins. The customers of our SoC partners who are going to market will get to market sooner because there's less work that they have to do, and therefore, the volumes come quicker. That's the point. So far today, that's our role in this. I wouldn't put it off the table for the future that we could look to provide some sort of services-based offering as well. Today, that's just not part of our plan.
Okay, clear. As a general trend, what do you think is the value proposition of Arm in networking? Is it just about power consumption, or is it more than that?
It's definitely more than that. Power is always a central part of our value proposition. That's clear. We talked earlier about the intelligent, flexible cloud and why we thought Arm would uniquely offer a pretty distinct value proposition in this trend that we see of intelligence being pushed from the endpoints down into the network for IoT, for analytics, for lots of different specialized services. It comes down to the fact that these use cases are highly varied, and because the Arm model is a range of suppliers will focus on going after certain segments, going after those different use cases, then a range of players will build the right combination of IO and compute and acceleration and storage for those different use cases.
Fundamentally, one of the big value propositions besides power is the fact that you can build these workload-optimized SoCs that fit into these cases. We absolutely believe and get validation that one size does not fit all, and a vanilla server just doesn't meet everything in the networks. It will meet some needs in the network, but not all. That's a second thing. I think what we see in networking, particularly in the forwarding plane, when you talk about packet processing, that responds much better to more quantity of smaller, more efficient cores than throwing big single-threaded cores at them.
In other words, we have seen time and time again these kinds of workloads where having 42 or 100 smaller cores is much more efficient on a sort of performance per watt, per square inch standpoint in delivering those workloads. That's where we'll win in that overall position.
Okay. Yeah, that's what about my last question, Robb, is, as you said, one size doesn't fit all. Do you think Arm-based System on Chip will be deployed in the whole spectrum of networking chips? I mean, access layers, routing, switching, wireless access point, baseband, et cetera, or more specifically to some niches? The very last question is, how do you see traction from incumbent semi vendors in networking, using Arm?
Yeah, we absolutely do see people in our ecosystem going after the whole range. It is true that early on, our current penetration into networking is in small to medium routers and switches and into the access layer. We absolutely have partners who have either publicly announced from Cavium and from Broadcom and others who clearly are going after the very high end, let's say the core of the network, which are very much high performance server applications in certain aspects of the Evolved Packet Core.
It's absolutely the case that some of the vendors will choose, that's where they're going to go and compete head on for the ultra-high performance, and others are going to be more nuanced and focused on attacking other targets within the network infrastructure where they feel like they can carve out a more effective niche based on their expertise and their capabilities. We do see the whole range.
Okay. Thank you very much, Robb. That was my last question. Thanks for the explanation. I will now give the hand back to Phil.
Thank you very much to Jérôme for leading the call today. Thanks everyone for listening. As a reminder, if you would like to learn more about the topics discussed today, you can find an online presentation on investors.arm.com. If you have any follow-up questions for Robb or myself, you can email at investor.relations@arm.com. Our next investor event is the Analyst and Investor Day, which takes place in London next Tuesday, the 15th of September. For those of you who can't make it to London, there will be a live webcast and a replay also on our investor relations website. Thanks again everyone, and goodbye.