Software is driving the world of networking more so than ever before, and the changes are just getting started. There are a lot of new approaches and new voices in the conversation. One of those is 128 Technology, which is bringing session-awareness to routing. With us today to talk about 128 Technology’s approach to routing and where they think the market is going is COO Patrick MeLampy. Prior to helping found 128 Technology, Patrick was co-founder and CTO at Acme Packet, which Oracle acquired in 2013.
TR: How did 128 Technology get started and what problem are you looking to solve?
PM: Over the last three years we have built a company founded on the belief that software-based IP routing can transform the way networking operates today. We believe that routing, to be done correctly, should understand sessions and services. One of our product’s differentiators is its understanding of sessions. When we talk about sessions, we're talking about full two-way client-server flow. We see routing sessions, rather than simply packets, as being a transformative technique. That’s our prime differentiator. We have raised $57 million to date to execute on our mission to transform networks.
TR: How do sessions and routing fit together in the internet as we know it?
PM: Most people think of the internet as one big giant inter-network of networks. But in reality, virtually every data center and every enterprise and every home has a private network that doesn't exchange policies or doesn't exchange routes with the network that they connect to, which is typically either an IPv4 public network or an IPv6 public network that people think of as the internet. There’s no way for IPv4 and IPv6 networks to exchange route policies. There is no way for a data center that is running on private network addresses to exchange policies with the internet. At every one of these borders today there's what we call a NAT or a NAT64. Address translators break the ability to understand or issue or create policies or rules for specific services that would extend from one network to another.
TR: How does this relate to SS7 signaling in voice networks?
PM: If you think about a voice network, a call is a session. The signaling is sent on a call-by-call basis so you reserve a pathway. It actually gets pretty sophisticated because you could fill a first pathway up completely, and then a second pathway for your overflow traffic. Those kinds of things aren't possible with IP routers. They don't have the concept of ‘full’. We think routers should groom sessions onto links. We think networking would be far more efficient and that we could get a lot more from our networks if they were smarter and could understand not just packets, but what these sessions are, how much bandwidth they are using, how many fit on wire, and when this wire is full then shift to a second choice wire.
TR: That sounds like a longstanding issue, how have we worked around it until now?
PM: The application guys, Google and Facebook etc., have figured out that they really can't count on the network to have any sort of deterministic behaviors. So they put session cookies in their applications, so then when a user connects they know who the user is. The application guys have danced around the fact that users are mobile and services are mobile, and they've been able to make things work. But the networks themselves haven't done anything to try to figure out how to pass information or pass requirements through these borders.
TR: So what is your approach?
PM: What we do is we add metadata to the first packet of a new session. When the packet goes through the border, the metadata actually goes through with it and communicates to the next network what the resources are required and what capabilities are required. We want to connect private networks to each other through public networks, or to allow data center interconnects to communicate with each other over foreign networks that are either public or private, and be able to end to end communicate route policies.
TR: Wouldn’t all routers need to have that capability in order to go end to end?
PM: If there were 100 routers in a network and we parachuted one of our routers into it, it would behave just like all the other. As soon as the second one of our routers parachuted into the network, there would be 2 smart routers and 98 dumb routers and those two smart routers would actually find each other and know about each other. They would talk to all the other routers the old-fashioned way and route the way everyone else routes today. But if there was a specific route that was known to the two smart routers, they would be able to perform that smart route between the two of them. A classic scenario might be that you have a particular area of your network that you're interested in improving whether it's data center interconnect or branch office connectivity, you could put smarter routers made by us at the edges of those networks. You can have some smart routers and a lot of dumb routers. We believe what people really want is multi-path routing, they want 80% of the traffic to go straight to its internet destination the old-fashioned way and 20% to go to a corporate data center or to a particular cloud-based public cloud or private cloud service with higher quality or with extra encryption or some other capability.
TR: Are we talking about proprietary changes to the protocols or are we talking about something standardized to the IETF or something?
PM: We haven't taken our metadata through a standards process, but we're quite willing to do so. We're also quite willing to document and publish it to anybody that wants to use it. It would have no value to us if people didn't use it or didn't want to see it or understand it. We're quite open about it and frankly, nobody else in the world that we know of is doing what we're doing with metadata, because we're not only inserting the metadata but we're also signing it, which allows you to do some very sophisticated secure routing from point to point. So we will go through the IETF standards process, but it's not an easy process to go through if you don't already have commercial success. Now that we have achieved commercial success I expect that we will be trying to begin the process of standardizing the metadata sometime soon.
TR: What kind of routing applications would see the most benefit from this kind of technology and what are they hoping to do with it?
PM: Very large companies and government agencies that are very interested in security have realized that we have hop-by-hop, authenticated-session, first-packet routing with subsequent packets transmitted with encryption. They really like the security but they dislike the fact that it started at the first router and they asked if we could extend that routing paradigm all the way to the end point. So, we wrote some software for Android, iOS, or personal computers where the actual IP stack is modified to insert and sign the metadata. It’s similar to the identity-based routing although it uses our metadata instead.
TR: What other real world use cases have you seen so far?
PM: One is a company with a gaming network that needs to track and manage game visitors so they are gaming in the same community or geography. But they don't really know who the gamers are until they connect, and by then it's too late, and so they are interested in trying to figure out how to get the gamers connected to the right servers. They thought if they could modify the metadata, they could figure it out, and so they wanted to insert some data fields of their own into the metadata. But the problem that everyone has today is that whenever they change or try to insert anything in the headers of IP packets, even though the standards say you can, what happens is they're always stripped out because they're considered a security concern and firewalls don't like them, and so they're all taken out. But when we put the metadata in these packets, we're putting it in the payload portion, which is pretty much guaranteed to get through it. So, it's not part of what normally IP routers would look at, and because we're a software-based router we can insert metadata in the payload and take it out and process it that way.
TR: You have been promoting the NG-WAN rather than the SD-WAN. What is NG-WAN and what makes it the better choice?
PM: There are a bunch of companies in the SD-WAN space, and to a ‘T’ all of them are building what people are calling overlaying networks or virtual networks on top of the current IP network. Because of our metadata insertion technique, we don't use encapsulation. We actually steer the packet through the network the same way that IPv6 segment routing does. We change the destination address and then restore it on the other side. It's part of what's in the IPV6 standard. We do it differently but it's essentially the same technique. So we don't do tunnels. So when customers ask if we have an SD-WAN solution, we say ours is actually one generation ahead. With our NG-WAN we can solve all those same problems, but we do it without tunnels. We do it with natural routing. The difference is that it's about 15% less bandwidth on average, because we're not sending extra IP headers on every packet. It also solves the problem created by aggregate flows. Current IP routers were designed to give fairness to each individual flow, and when it comes to things like which packets randomly drop, or how to provide quality of service, they give fairness to each individual flow. When you put 100 small flows into one aggregate flow, routers treat it as a single flow and so it gets punished a little more. With our technique, single individual session appears as a unique flow to the router network, and so it actually provides much better fairness. We also mitigate packet fragmentation. So as compared to SD-WAN, NG-WAN has all the same exact routing use cases, the same exact security, and the same exact ROI. It's just that it's not an overlay network, and it doesn't use tunnels. The other main difference between traditional SD-WAN solutions and what we offer is that our software has so many use cases, not just branch connectivity. 128T routers can be used anywhere a traditional router is used, so besides branch connectivity, we have a solution to interconnect data centers, to deliver network as a service, to connect users to cloud service providers, and more.
TR: So how does the business model work. Do you sell routers with your software directly?
PM: We don't sell hardware, only software. We recommend hardware platforms and will put up a web store where you can source them directly from our website. But they are guaranteed to run our software correctly. We do have customers that will run it on their own hardware and it works fine too. It isn't as picky as you might think. The question is how fast does it work, and the hardware we recommend all supports it running as fast as is possible.
TR: What kinds of customers have you found success with so far?
PM: We have six or seven customers, two of which are announced. Our customers are either enterprises or managed service providers. We have 40 proof of concepts that are underway right now. Internationally, we opened up our European office within the last month or two, we have folks in Japan.
TR: What is the next step for this technology? What do you have on the drawing board?
PM: All of the SD-WAN vendors and all the multipath router solutions today have added the ability to look at network conditions in real-time and decide how to modify how they route. Interestingly, enough, none of these solutions today is for more than a single link. None of them are multi-hop. So what we're working on now is adding multi-hop routing to our fancy world of intelligent routing. For example, if you use SD-WAN to get to a data center it will get you to the edge of what is the best data center for you at the current time. But it doesn't know what's inside the data center. It's almost like your driving in a car to New York from Massachusetts and you know all the road conditions along the way, but as soon as you hit the New York line, they disappear. You have no concept of traffic or anything in points beyond your state border. That's how routing works today, even with SD-WAN. There's no sort of data from the next network that is shared with the previous network about road conditions further ahead. SD-WAN solutions get you to the edge, but then you're out of gas. We're going to put our information in the metadata end-to-end and be able to harvest it and learn about what's going on in the next network or the network two hops away so that you can improve your routing.
TR: What’s the biggest challenge you see ahead for SDN and routing?
PM: I think there's a massive, massive shift going on. There's never been a time like this in networking where both the client and server sides are moving targets. Because of user mobility, e.g. people working from home and working from Starbucks, the client side is completely all over the map. Now with the server side moving because of the cloud, the other side of the communication is moving all over the place as well. To assume that networking isn't going to change is just foolish. When people start thinking about how it's going to change, the first thing that everyone did was to add overlays and tunnels. The industry proudly proclaimed, "We'll just add another layer over the top," and now we’re going to create “Virtual Networking”. I have to say that there's so much dissatisfaction in the industry with this approach that can’t be easily measured. They're adding more layers, and it's too complicated. When it doesn't work, it doesn't take five minutes to fix, it takes four hours to fix. And so, I think we're headed into some very revolutionary times in routing and networking where there's going to be some really big changes and some new people in town and it's very exciting.
TR: Thank you for talking with Telecom Ramblings!