There’s been a major shift in networking over the past three decades, one that has created many of the challenges we see today. There have also been attempts to address some of the fallout of the shift, none of which have been successful. Today, there may be another such attempt emerging, which has some interesting if somewhat opaque ties to past initiatives. Will it work, or not?

Up to the 1990s, we lived in a connection-oriented world, network-wise. The Internet created “connectionless” service; you had an open pipe to the Internet and others on it, and you simply identified your desired partner in a traffic relationship by URL/address and sent. The Internet had no notion of connection, no notion of settlement, and this model has dominated the world largely because it supported such a wide variety of to-consumer experience deliveries that consumed network resources and generated revenue.

Telcos, in the early 2000s, recognized that IP networks had won over the connection-oriented counterparts. Attempts to make things like ATM the universal underpinning of networking failed because any sort of traffic with commercial value could be mapped to IP, and IP was obviously destined to be the overwhelming service-layer protocol. Why, then, would you want to build an underlayment via ATM? But the bill-and-keep approach of IP networks, the death of settlement, is a big reason why ISPs have suffered revenue-per-bit erosion over time. What telcos wanted was a mechanism to create IP services across multiple providers that retained connection features, like inter-provider settlement. They wanted federation.

At this point, a router vendor, Juniper Networks, came along with a concept that was originally called “the Infranet”, which meant “infrastructure network”, but later became IPsphere. In a paper on IPsphere, we see a fairly detailed picture of its goal and an introduction of a three-layer structure that puts infrastructure at the base, services at the top, and policy and control in the critical middle. IPsphere envisioned a future where federation agreements among telcos, and a framework for automatic provisioning of IP services across boundaries between operators (via “Association Points”) would enable services to be offered that had QoS guarantees, for both business and consumer services. This would be a sort of parallel to the best-efforts Internet.

The paper was published in August of 2009, which is ironic in a way because the initiative lost steam at about this point, defeated by a combination of competitive vendor behavior and the fact that the trend in the IP world was to make low-cost best-efforts service good enough. Regulatory barriers to Internet QoS and settlement contributed a final blow.

That was then, and this is now, and telco problems remain. To solve them, though, they need a strategy that’s different from the Internet, and they need a way to create that elusive federation. A startup, MaiaEdge, who got their Series A funding and describes their goal as “Building for the Big Middle”. The key people came from (you guessed it) Juniper, and though I don’t remember either of the two from the IPsphere days, it sure seems to me to be aiming at a similar future service goal, modernized to focus more on business services (and on AI) and more linked to the Mplify Alliance, a standards group previously known as the Metro Ethernet Forum (MEF). Business Ethernet services are the access foundation of MPLS VPNs, and of course are “metro” in nature, as the name suggests, so the topic of federation is important for the body, and its members.

Three of the key people in MaiaEdge are formerly a part of SD-WAN vendor 128 Technology, which was acquired by Juniper and represented the best of the SD-WAN plays, in my view. The technology isn’t described in enormous detail, but it includes the notion of “association” at provider boundaries, and supports service relationship setup through automated processes. In other words, it seems a modern take on the IPsphere federation story.

Could this work, when earlier initiatives have not? It’s really hard to say for sure, at this early stage. We have to dismiss a lot of (if not all of) the early positioning, because getting venture capital is a lot different from real operations. In politics, you have to kiss babies. In startup-land you have to kiss the current hype trend, which today is AI. AI workloads are not, at present, any real opportunity. However, real-time missions that might or might not involve AI are the most realistic path of evolution from today’s on-premises IoT, as I’ve noted.

Real-time services are the big opportunity for telcos. Edge hosting is the real opportunity for cloud/hosting providers. Both evolve from one of the two primary facility-based activities I’ve cited in THIS blog. I think that this is where MaiaEdge could get real traction, particularly if their story included some virtual-network components that related to the best features of 128 Technology’s SD-WAN. Real-time-federated SD-WAN-like services sure sounds like it could be a winner to me.

One hurdle that federation has to deal with today was an early challenge for it—telcos themselves. The problem with federation is that it admits groups of smaller players into the Big Game, which the Tier One telcos might otherwise hope to keep for themselves. But few Tier Ones can boast universal geographic scope, and so arguably federation gives them a broader opportunity without excessive capex. For real-time services, though, there is no current infrastructure to provide high-QoS connectivity anyway, and because real-time opportunity grows gradually in scope, a provider could dip its toes into federation for a new service without necessarily creating more competitors in the legacy space.

The Mplify connection here could be a plus, or a minus. On the plus side, it could build an early metro-Ethernet-expansion model for QoS that, by being metro Ethernet, doesn’t impact current VPN services by introducing new players through a federation of the small. On the minus side, if the real-time nature of the opportunity isn’t exploited quickly, the whole initiative could turn to legacy services and increase competition there. What MaiaEdge could do, perhaps, is to create the model that IPsphere’s vendor-disrupted consensus couldn’t create, then promote it for specific real-time missions.

I think that the basic principles of federation are important, perhaps even critical. The problem with the Internet is that security is elusive, and the economics of premium solutions even more so. Can we evolve out of our current network-service doldrums, to something enterprises would pay for, without solutions to all of this? I think that the solution ingredients MaiaEdge proposes, which are those inter-provider association elements, are also important and likely mandatory. There is, IMHO, no escaping either the reality of the challenge or the specifics of the basic technology associated with meeting it.

Yet, we escaped this all back in around 2009. The problem then was one of competing interests. Vendors winning in the old game didn’t want a game change. Operators always saw competition more of a risk than they saw opportunity as a benefit. The real need for federation is visible, but no more popular today than it was decades ago. Can MaiaEdge or the Mplify Alliance navigate these old, and then-fatal, issues? I think we see more of the value of federation, and I think that the combination of Juniper and 128 Technology brings a new technical slant to the problem, so it will be interesting to see how their story develops, and whether they can engage with the Mplify community without getting derailed by the group politics.