Martin Taylor, the Chief Technical Officer of Metaswitch Networks, has been working in software protocols and networking for more than 20 years. He joined Metaswitch in 2004 after pioneering converged voice and video as CTO of CopperCom, an early softswitch provider.

At CopperCom, Taylor led the ATM Forum effort to create a standard for Voice over Broadband (VoB) interoperability. The company was also one of the early leaders in softswitches, which run voice applications as software on packet-based networks -- one of the earlier IP-based applications of Software Defined Networking (SDN).

Softswitches, which abstract IP voice switch functions from hardware, were one of the first SDN applications. Metaswitch has been building IP-based softswitches since 2000, and it is also a leading provider of IP Multimedia Subsystems (IMSs) and Session Border Controllers (SBCs). The company was producing SDN and Network Functions Virtualization (NFV) technology before they became hot industry buzzwords.

More recently, Metaswitch has embraced the cloud model by creating Project Clearwater, an IMS platform that runs in the cloud and is also available as open source. Clearwater is designed to run in the cloud and can lower the cost of running IMS applications to less than 2 US cents per subscriber per year, according to Metaswitch.

In 2014, running with the open-source theme, Metaswitch released Project Calico, an open-source effort for large-scale NFV and cloud implementations from Layer 2 to Layer 3.

Metaswitch was the dominant division of established telecom technology provider Data Connection (DCL). It was reformed under the Metaswitch name and received venture capital investment from Francisco Partners and Sequoia Capital in 2008.

Rayno Report: Now SDN and NFV is supposed to be taking over the world, but Metaswitch has been virtualizing things for a while, yes?

Martin Taylor: It's about software, isn't it? We're fundamentally a software company. We started by licensing to OEMs -- protocol stacks, control planes. When we decided to get into packaging that software to market for network operators, in those days, network operators didn't buy software, they bought appliances. So we packaged our software on CompactPCI and ATCA -- essentially, totally standard hardware platforms.

We continued that strategy and built our software on an x86 standard platform instead of proprietary platforms. The best example of that is our session border controller, where we entered the market three years ago or so with the first SBC, which was based on x86. Three years ago we demonstrated it running in the cloud. This is before the NFV whitepaper came out or anybody knew what NFV was.

We believed that, seeing what was happening in the Internet world, cloud was going to come to telco land sooner or later. So the whole NFV movement has been extraordinarily positive for us. When that first NFV whitepaper came out we were over the moon, because we saw this as a huge endorsement of our approach.

We also built stuff just for the cloud, and that's Project Clearwater. I think it's arguably the first virtual network function that wasn't a part of some earlier product, architected from the ground up to run in the cloud. Our development environment for Clearwater is Amazon Web Services. This is such a generic cloud that if you can run it there you can run it anywhere.

RR: Tell us about the open-source strategy.

Taylor: The thing about open source is that if people want support, and you are running a revenue producing network, generally you buy support. The wonderful thing about open source though is that you try it before you buy. People can experiment with this stuff with very low friction, and a lot of people have. We've started a lot of sales campaigns on the back of people trying Clearwater and liking what they saw.

It then turns into support revenue if those customers choose to go into production. But it also pulls through a lot of other commercial product. Clearwater is an IMS core, but you still need session border controllers, media gateway controllers, media gateways, telephony application servers, management servers. There's a bunch of stuff that you wrap around it, all of which is commercial software.

RR: And Calico?

Taylor: Calico was born from a part of our business that provided networking software to OEMs. You appreciate that we have built up many years of assets for control planes. The only market for those historically was OEMs. Now, we move into this new world where the boxes are generic and the software has a life of its own. This creates new opportunities for the software assets that we have.

Calico came from us critiquing the approaches taken to cloud networking. If you look at the way OpenStack does networking out of the box, what you see is the notion of an overlay network sitting on top of an underlay network. The overlay provides emulated Layer 2 segments that tunnel through an underlying Layer 3 infrastructure.

You might ask: Why did they do things that way? It came out of an idea that as we virtualize the world, virtualized things sit on a virtualized Ethernet. So if we virtualize that and you try to use Ethernet VLANs [Virtual LANs], you run out of IDs and it's not very scaleable, so we have to break out of that -- so we are going to virtualize over a Layer 3 underlay network. What you end up with is a very complicated protocol stack and a fair bit of inefficiency. It's difficult to troubleshoot. And it also creates an artificial wall around the cloud, a network wall. To penetrate that wall you are going through network address translation. You have to come out of the physical network world and enter a world of tunnels and encapsulation.

Calico does away with all that. It just says, basically, what you want when you connect to a machine is you want IP connectivity. Let's just connect directly into the IP data center. Instead of doing that with a vSwitch, you have a vSwitch in each compute node, typically Open vSwitch or a proprietary version. In the case of Calico you connect through a vRouter. So what we do is we essentially build a software router and connect all the virtual machines to that and then they talk to the physical fabric which is typically a big Ethernet network. It's a software-defined network, we are creating software routers in each of these end points we are populating forwarding information bases. We are using Border Gateway Protocol (BGP) as the control plane to advertise routers and we are installing  Access Control Lists (ACLs) to enforce policy.

In the OpenStack world we have a Neutron plug-in. We are also getting good traction with Calico in the container world. The whole Docker thing is becoming very hot right now. The difference between containers and virtual machines is you might have 10s of virtual machines, but you could have 100s of containers, so they stress the network in a different way. The extra complexity you get with the overlay/underlay approach is made far worse with a container situation. The simplicity of Calico comes into its own with containers.

RR: It seemed as if we just got everybody using virtual machines, then containers came around, and now everybody says, "Let's use that!"

Taylor: Exactly. It's horses for courses. There are use cases where containers make a lot of sense, and there are use cases where VMs make a lot of sense. Our view is that, certainly in the NFV space, there is a role for containers and there is a roll for virtual machines. The simple way of characterizing this is if you are offering an enterprise service, where what you want to do is instantiate an instance of a particular network function, or a service chain on a per enterprise basis, it makes sense using containers because you can pack hundreds of them onto a host. Virtual machines have so much more overhead that you are consuming a lot of resources.

If you are talking about a massive service like IMS where you have millions of VoLTE [Voice over LTE] subscribers, you're probably going to use virtual machines. Because you might have big virtual machines but only half a dozen virtual machines on a host serving hundreds of thousands of subscribers. So it doesn't really benefit you to go to a container for that.

So we think containers and VMs will have to coexist in the NFV infrastructure. That's another good reason to adopt a networking approach like Calico, because it provides a level playing field that virtual machines and containers can communicate with each other on.

RR: How much of this is really being adopted in service provider networks right now?

Taylor: What service providers are doing today, to the extent that they are virtualizing network functions, they are tending to do it with the tried and trusted, which is VMWare right now. So, a lot of them have OpenStack labs, and they are doing trials and proofs of concept. But if they are putting it into production; they are doing it on VMware. That's what we're seeing.

RR: You haven't mentioned Cisco or ACI.

Taylor: It's still relatively early days for that kind of OpenStack-based NFV. Cisco may well be in lots of trials. There are only a handful of operators around the world that have been courageous enough to deploy a real virtualized network to put functions in a production environment. We've seen quite a few of those, because we were very early in this space, and people are scrambling to catch up.

RR: Are there specific cases that you can point to that have been the most successful?

Taylor: Probably the most high-profile one we can point to is the Virtual SBC deployment with BT. That was a classic case of software and virtualization reducing time to market. They were scrambling to launch a new service -- fixed mobile convergence for business. That service required that they had an interconnect point between their network and a mobile partner's network. Their incumbent SBC vendor quoted them three months to deliver a box, and they couldn't wait that long.

They called us up -- they had a rack of servers running VMware -- and they said, "Can you put your software on it?" So we did, and we were up and running in a day and a half. They had the whole thing working, fully tested by 10 days. And they launched it a few months later.

RR: What about white-box technology. Is that a term you use?

Taylor: People use the term "white box" usually in conjunction with commodity switches -- more on the switching side than on the server side.

RR: OK, so you were talking about servers. But are you going to be moving into this area?

Taylor: We have an OpenFlow controller. It's called Gulfstream.

RR: You guys spend a lot of time in Florida, don't you? Clearwater, Gulfstream...

Taylor: [Laughs]. Well, yeah, absolutely. I lived in Florida for a couple of years, and when I was head of product management, I said OK, we're going to name projects after cities in Florida. So that's where Gulfstream, Clearwater [come from] and there are a few other internal names as well. Calico was something different.

So Gulfstream is an OpenFlow contoller, and it drives OpenFlow switches or white boxes. It's still a very early market, and we're not seeing a big uptake of those kinds of things. That's not to say it's not happening. We talk to people like Cumulus, and we know that they have done some good stuff. It's definitely starting to displace some of the brand-name stuff in some data centers, but not so much in the telco space yet.

RR: Somebody said to me recently that they think in the future, service providers will be data centers. Do you think the service providers are a little slow to adopt these technologies?

Taylor: They have got a massive installed base. As you have pointed out, Operations Support Systems is a big issue for them. So they've got a big ship to change direction on, and it takes a while. It's a well recognized fact that the biggest barrier to NFV is not technology, it's organization.

Unlearning the historical approach -- where you have a bunch of people that define a service in terms of what it delivers, and you choose a vendor of boxes to deploy that service, and then you rely on those boxes, and moving that to a situation where you are building a generic infrastructure and the services are created with software -- that's a big cultural transformation. That's well recognized by the telcos themselves. AT&Ts whitepaper on Domain 2.0 makes no bones about the challenges they face with organizational transformation.

What we see is a big effort to take IT expertise and adapt that expertise and meld it with the people who build out the network, understanding services and service-level expertise. They need to fuse that expertise together.

When you look inside telcos to see how that's working in practice, you see two things going on in the design of a long-term architecture for NFV, looking five to ten years out. We've seen very encouraging signs of a change in thinking in the procurement arm. Even if the long-term vision of NFV is not out there, and we have a choice of buying a box and buying a piece of software that we can run virtualized -- why would we buy the box? It doesn't make sense. We're are seeing some strong top-down direction to procurement: Do not buy boxes; buy virtualized network functions; we'll figure out how to deploy them. We know we can trust VMware, and when we know OpenStack is ready we'll make the switch, or maybe not.

RR: So, that's good for you.

Taylor: Oh yeah, it is. NFV has been extremely positive for us a business. We have been justifiably talking about early leadership. It's enabled us to get great partnerships going. This is one of the things about the Clearwater open-source space. A bunch of companies in the orchestration space downloaded Clearwater and installed it as a great way to demonstrate the capabilities of their orchestrator, because it's such a cloudy, architected thing.

RR: What kind of things do you track with Clearwater? Is it downloads?

Taylor: The thing with open source is you can't really track who's downloading.

You can do a little bit of detective work and trace back IP addresses. But people call in out of the blue and say, "We have been playing with Clearwater a while, now we want to deploy it." The mailing list has been pretty active. A lot of the time you don't know who's who, because a lot of people use their Gmail addresses, and they are doing it for a big service provider. It's an open-source thing. If you join an open-source community you usually do it as an individual, not as part of your company.

Open source is a very powerful aspect of this new movement. One of the things we said to the Clearwater development team: If you are working in this new world of cloud, think the same way. We always built our own software. Tear up this rule book and build it the way Facebook built it.

RR: You mentioned Facebook. Are you involved in Open Compute?

Taylor: No, not really. We're aware it exists, but we're completely not hardware people.

RR: Too much metal?

Taylor: Exactly. The key thing is, when you are virtualized, you are quite a ways from the metal, you want to keep away from it.

RR: But that's better for you if the movement is toward standardization.

Taylor: We have lots of people who are building infrastructure who come to us, and they say, "Can you leverage it?" We're saying: "Why would we, if this creates a dependency?" If we tie into some underlying hardware platform capability, then all that does is restrict our market -- it creates fiction.

RR: My big question about all this stuff: If everybody goes to commodity hardware, and everybody goes to open source, it's going to be harder to differentiate, isn't it?

Taylor: But here's the thing -- the commodity-ness is all in the platform. It's in the underlying infrastructure, the servers, the physical fabric, the hypervisor... All of that will be commodity or open source. The virtualized network functions, on the other hand, which implement the services, are not going to open source. You're not going to see the big router vendors putting out an open-source PE router. There's way too much value in that stuff.

The value is going to start concentrating in the software space. That's not to say there's not going to be a lot of value in the cloud software space. Companies like Red Hat, Mirantis, and Canonical, they stand to benefit from this NFV thing. But the value will be sucked out of the traditional networking appliance.

RR: Yes, and that's what I've been saying. But it's fascinating to watch the mega-vendors run around to become white-box switching vendors. How is that better? It's a bloody place to run.

Taylor: It is. It's a race to the bottom on price. The question is: Can you wrap enough value on this commodity for people to choose you rather than somebody else?

RR: What do the service providers think?

Taylor: They're still going to have preferences. They've been buying from those kinds of vendors for their IT shop for many years, and they have particular vendor preferences, even though you can argue it's already commoditized. They're importing that into the NFV space.