Multiprotocol Label Switching isn't just for carriers anymore. More enterprises are considering the high-performance
switching technique to ensure a high quality of service on VPNs and VoIP implementations. However, building an MPLS network has traditionally been expensive and tedious.
Azhar Sayeed is trying to change that. Sayeed, a strategist and customer liaison in Cisco Systems Inc.'s software-focused Internet Technology Division, recently spoke with SearchNetworking.com about the pluses, pains and potential of MPLS.
Cisco has said that MPLS technology is essential to creating scalable VPNs and end-to-end quality of service (QoS). Why is that?
Azhar Sayeed: There are a number of things network designers and operators can do with MPLS. If there's congestion, they can use traffic engineering to get traffic away from congested links and make traffic flow easier through the network. The second thing is you have the ability to priority queue different types of packets based on marking—it could be a code point on the IP header or the IP precedence or type of service field. That gets mapped to the MPLS domain, and you can do the same functions in an IP network.
What's the biggest misconception about MPLS?
Sayeed: People think it can address all of their networking needs. It doesn't. It's a wonderful technology to integrate their Layer 3 networks, to build VPN services or to transport Layer 2 services across the network, but it does not solve user identity issues or some of the other specific application requirements that enterprises have.
What about improving QoS?
Sayeed: That's another misconception, that by default it provides QoS. It has methods to improve QoS, and it can steer traffic away from congested links, but there is no inherent, built-in QoS. But what we've seen recently in the enterprise domain is a larger number of enterprises are interested in traffic separation.
What's Cisco's strategy in terms of encouraging MPLS adoption? Are you trying to guide how enterprises use it?
Sayeed: We don't drive any particular technology religion to our customers. We encourage them to pick the tools that they can get from Cisco to develop a solution that suits their business models and network technology requirements. With MPLS, if they want to deploy it to meet their needs, we will work with them. But we wouldn't push a certain technology down somebody's throat.
There's been speculation that the growing popularity of voice and video over IP will in turn increase the popularity of MPLS networks in the enterprise. Is that what you're seeing?
Sayeed: Actually, I wouldn't necessarily tie it to the growing popularity of voice and video as much as to the need for more stringent requirements for QoS in those networks. The question then becomes, what's the best means available to deliver QoS? Today the best there is in terms of a better QoS model while leveraging the IP infrastructure is MPLS.
But another element we tend to forget when we talk about voice and video is admission control. If more and more voice gateways produce Resource Reservation Protocol capabilities for better admission control, and map that to the differentiated services model of the core IP network, I would think that would be the right model to deploy voice and video on those kinds of networks.
Does that mean MPLS is the answer for companies looking to guarantee end-to-end VoIP QoS?
Sayeed: If you couple the requirements of QoS along with elements like traffic separation, absolutely. If you don't and all you have is one flat network with no VPN requirements, then it's not a requirement to build that QoS model. But I would say yes, it may be a recommended strategy.
In that case, why wouldn't every company want to implement MPLS, especially when greenfield networks are involved?
Sayeed: MPLS doesn't come for free. You have to know how to manage the basic technology of it and you have to be comfortable with it. Evaluate what you would otherwise do versus what you could change if you deployed MPLS in your network and then ask yourself, 'Is it worth the trouble?' A lot of people know how to manage IP networks, but you have to learn the finer details of managing the elements MPLS. But know your pros and cons and give it a fair chance.
To that end, some would say that setting up an MPLS network isn't worth the trouble because in many cases it requires a separate subnetwork, a la Sonet. What's your response?
Sayeed: I don't know if I buy the argument that a separate subnetwork is required, but if you deploy MPLS, you have to know certain things, like how to debug the additional elements MPLS adds, whether you're doing VPNs or PGP or traffic engineering.
Having said that, we are doing things to make that better. For example, some of our enterprise customers have asked us to simplify the configuration for MPLS. So we've taken that into account when building our products, and if there's value we'll develop it and try to simplify the configuration model.
Can you give me an example?
Sayeed: We're working to improve some of the things involving Label Distribution Protocol. Instead of having three steps to MPLS configuration, we want one step. Where you have OSPF enabled, we want to automatically enable LDP on those interfaces. It's just a small example, and we'll continue to make more enhancements in the space as we get more feedback from customers to improve the products.
Earlier this week, Cisco announced new MPLS inter-provider capabilities. What's the impact of that announcement for enterprises?
Sayeed: What we've just recently announced is some major enhancements to our portfolio products to do better inter-provider capabilities, such as better VPN, multicast, traffic engineering capabilities. A global enterprise, for instance, usually wants to deploy its services across three or more providers, and this announcement will provide better QoS and multicast services across administrative domains, and the ability to provide Layer 3 VPNs across heterogeneous networks.
As you know, there's no single MPLS standard. Has that hindered enterprise MPLS adoption?
Sayeed: No, not at all. I would argue otherwise. The basic MPLS standards have been ratified and have been stable for a long time. RFC 3036 [LDP] for example, has been around for some time. The traffic engineering standard [RFC 2702] has been a standard for a long time. There is more work to be done, and those areas are part of the interoperability discussions that are happening now.
What's the best way that an enterprise can test or evaluate MPLS without making a major equipment investment?
Sayeed: We provide MPLS capabilities with much of our equipment, including the 7000 Series and the 12000 Series routers, as well as our CRS-1 boxes. For many of those routers, it is just a matter of a software upgrade, and some of the devices already have MPLS capabilities built in. So if an enterprise is using some of that equipment, they can fairly easily validate MPLS.
Finally, what does the future hold for MPLS? Will the majority of enterprises have MPLS networks in five years?
Sayeed: It would be tough to say that the majority would, but it wouldn't surprise me. Certainly, MPLS is the right choice for any large enterprise with requiring network segmentation or VPNs, and that's what is driving today's deployments.