© 2022 Black Swan Telecom Journal | • | protecting and growing a robust communications business | • a service of |
Email a colleague |
August 2014
In the network equipment business, there’s a constant tension between proprietary innovation and industry standardization.
A network equipment provider (NEP) always praises the efforts of industry standard groups, but also seeks to offer a proprietary add-on to standards that gives itself a competitive edge.
This is only natural. A NEP is not going to invest R&D in ground-breaking technology unless there’s a potential payoff down the road. Yet, it knows full well that one of the best paths to networking profits is to transform a once proprietary technology into an industry standard one.
The success of Ethernet is a great example. Back in the late 70s and 80s, Ethernet was battling with competing LAN technologies like ARCNet, FDDI, and Token Ring for acceptance. No one quite knew which protocol would eventually prevail, and the major computer industry titans were jockeying with each other to get on the winning horse.
It was Xerox PARC who ended up patenting Ethernet in 1975. And then in 1979, Robert Metcalfe, one of the co-inventors of Ethernet, left Xerox to co-founded 3Com.
Now even though Ethernet’s protocol was already out there, 3Com’s engineers had enough of a head start in the standard that they soon became the global leader in Ethernet networking cards: 3Com grew to a $5 billion business by 1999.
Of course, 3Com not only had an edge in Ethernet domain knowledge, it also cleverly gained the support of key industry allies like Digital Equipment Corp, Intel, and Xerox. In short, it made money by creating a de facto industry standard.
Well, there’s another key networking technology out there — MPLS. It’s caught fire in the last decade and it’s pretty crucial to telecom’s future.
Yet there’s a problem: it’s still not widely adopted by all telecom service providers. For the most part, the technology is so daunting that tier 2/3 carriers and cable providers haven‘t really found an efficient way to roll out MPLS to their SMB and large enterprise customers. And one major technical sticking point with MPLS is the need to manage multi-vendor devices.
But one company, WebNMS, a provider of network/element management framework software is supporting a new solution and claims to be the first widely available solution that automates both the assurance and provisioning of a multi-vendor MPLS. Joining us to discuss the MPLS trend is Prabhu Ramachandran, Director of Product Management of the WebNMS product line.
Dan Baker: Prabhu, before we talk about your new solution, I think readers would appreciate a quick backgrounder on the significance of MPLS in today’s telecom world. |
Prabhu Ramachandran: Absolutely, Dan. Happy to. It’s an easy concept to understand actually. MPLS stands for Multiprotocol Label Switching and as its name suggests, MPLS uses labels to specify virtual paths between network nodes. Packet-forwarding decisions are made solely on the contents of these labels, not where the router says to go.
Now it turns out that labeling an IP network enables some pretty impressive magic: it can basically turn a best-effort IP network designed for email into a virtual high quality circuit, one that mimics the superior traffic engineering qualities of a dedicated Frame Relay or ATM circuit.
This capability to encapulate other protocols and deliver them at high levels of quality across the network has made MPLS the king of WAN protocols.
A key factor driving MPLS today, of course, is the great interest telecoms have in selling B2B to the enterprise. The consumer market today is less attractive since ARPU is not going up and competition is stiff. Yet because so much activity is moving to the cloud, enterprises actually need more bandwidth services -- across their offices and data centers. For this reason, both MPLS and Carrier Ethernet are booming.
Now if a BT, AT&T or Sprint designs a VPN for a large enterprise customer to connect its remote offices and cloud data centers, 9 out of 10 times today it will be built on an MPLS framework.
And as more and more of the world’s services move to IP networks, it’s a safe bet MPLS will grow with it. Plus there are some new and upcoming High Definition services such as HD-Voice and HD-Conferencing that will ride on an IPX network enabled by MPLS.
Of course, the older WAN technologies like Frame Relay and ATM are still around, but they are steadily going away because -- unlike MPLS -- those technologies don‘t leverage the world’s basic network building blocks: IP packets and routers.
Great, Prabhu. But now we get to the key question: how come MPLS is a technology dominated by large NEPs like Cisco and Juniper, and supplied by mostly big carriers? |
NEPs are looking out for their own self-interest like everyone else in business. So it’s to their advantage to adopt a more advanced and proprietary version of MPLS than what’s generally available as an open standard.
So a Cisco or Juniper have designed their product to manage a network of their own devices. And in most cases a large carrier who builds these MPLS networks will choose two vendors and play them off one another. For an example, a Cisco shop might decide to populate its MPLS networks with 90% Cisco devices and 10% Juniper — or vice versa.
And up to now, only the large carriers have had the capital to invest in building their own multi-vendor MPLS networks. They’ve been willing to go through that trouble because it enables them to serve Fortune 500 companies.
So how does your multi-vendor MPLS work, who else is offering this technology, and what are the challenges of building something like this? |
Dan, our path to a multi-vendor MPLS solution was easier because the NMS/EMS framework we’ve been selling for 15 years helped us build things quickly.
The challenge for all vendors, of course, is to fully understand how each NEP vendor exposes data and interfaces to protocols. Still, the toughest job is simply understanding the pain points of customers and their priorities.
The WebNMS approach is to discovery across Layer 3 and Layer 2. We discover all these services: VPN services, IP MPLS, VPN MPLS services and then model them as standard objects, and do performance monitoring, Quality of Service analysis and provisioning.
For example, a customer can create an MPLS tunnel or MPLS path in the software.
Competitors are out there too such as CA, EMC, and Solar Wind. Many of these solutions focus on the service assurance aspects of the MPLS problem, such as performance measurement.
Our own solution is a full end-to-end solution that covers discovery to management as well as performance and provisioning. The NEPs we support today include Cisco, Juniper, Huawei, Broadcom, Ericsson, Alcatel-Lucent, and devices from several less famous players.
What our initial customers particularly like is we supply a full customer portal for them that exposes SLA reports for the MPLS services.
What sort of customers are buying a multi-vendor MPLS solution today? |
The market is just getting started. The first customers of multi-vendor MPLS solutions are enterprises. It’s all over the map: oil companies, companies with submarine networks, even a cruise ship company. Some of these cruise ships have their own MPLS networks serving 100 vessels around the world and they want to provide connectivity.
We also supply MPLS solutions to mid-sized enterprises such as a retail chain with stores and, say, 30 routers and stores to connect across 2 or 3 states. Other big markets are the universities, schools, and government networks.
Sooner or later, we figure there’s going to be big demand for MPLS solutions from tier 2 and 3 carriers and managed service providers. The big attraction for them, of course, is to get access to MPLS as a much lower price point so they can serve enterprise customers.
The big problem enterprises generally face today is supporting MPLS beyond the first two NEPs they currently support. For instance, if the enterprise already has Huawei and Cisco devices in their network, on average it takes an engineer about eight weeks to bring a third vendor device into the mix.
That’s a cost most enterprises don‘t want to incur. But in cases like this we will often supply that third connection to the customer at no charge, just so we can get them as a customer. Of course, the third party NEP vendor is also pleased to partner with us because we’re helping them gain a new client. So everybody wins.
How do you foresee this market evolving? |
Long term I think the future of MPLS is to make it available via a single SDN/NFV platform that does service orchestration. At WebNMS this migration path is on our roadmap.
When that day arrives, an enterprise customer will be able to dynamically create Ethernet or MPLS services, so a Procter and Gamble let’s say can get a bandwidth service from CenturyLink or AT&T.
In turn, the software can execute commands on routers and switches to create a bandwidth circuit between two different locations. Then, using our NFV API, they will configure a routing appliance, a firewall, AAA, or security for this service.
And the SDN/NFV will automatically create the physical circuit and also go and create all these logical entries, such as in the CRM database, in the firewall, in an AAA server like Radius or LDAP.
We figure, the large NEPs and service providers have already paved the way for MPLS is be a big winner. And this opens the door for a more multi-vendor approach that will enable tier 2 and 3 operators to get in on cloud and VPN services that enterprises are eager to obtain.
Thanks, Prabhu. The notion that tier 2 and 3 carrier can get in on the game of offering enterprise-grade networking is pretty exciting. Good luck in getting your solution moving. |
Copyright 2014 Black Swan Telecom Journal