x
Optical/IP

Is Sprint Rethinking MPLS?

Sprint Corp. (NYSE: FON) is softening its previous skeptical stance on Multiprotocol Label Switching (MPLS), driven by its recently announced efforts to expand globally (see Sprint Expands IP Services).

In a conference call with industry analysts about its IP expansion late Friday, one executive left the door open for MPLS after he was questioned about its popularity in Europe, where the protocol's caught on big.

"Recognizing the need for MPLS VPNs... in terms of implementing those types of features, [we're] certainly looking at that..." said Barry Tishgart, Sprint's director of data product marketing. He added that he "didn't want to go much farther" in clarifying his point.

This is considerably more waffling than Tishgart did last winter, when he insisted Sprint was ready to tackle the European market without bending on MPLS (see Sprint Spurns MPLS for Global VPNs).

Tishgart maintained last week that Sprint's adoption of Layer 2 Tunneling Protocol, version 3, and MPLS are two sides of the same virtual routing coin. He didn't argue that Sprint's approach is more efficient than MPLS. And therein lies a new, more amiable stance.

Sprint has stood apart among large carriers on MPLS. Rival interexchange carriers like AT&T Corp. (NYSE: T) are pushing the protocol hard, and so are the regional Bells (see AT&T Talks Up IP VPNs and BellSouth Unveils MPLS Backbone).

Officially, Sprint's position is unchanged: MPLS won't be included in Sprint's core IP network, says spokeswoman Barbara Mellott.

But Mellott says Sprint now "is looking into" a solution for including MPLS in edge networks. She won't name prospective vendors, but Sprint's primary supplier of IP gear is Cisco Systems Inc. (Nasdaq: CSCO).

Cisco is also the key supplier to British Telecommunications plc (BT) (NYSE: BTY; London: BTA), which has been especially aggressive in its endorsement of the protocol (see BT Boosts US Backbone).

Cisco wouldn't comment for this article.

It remains to be seen whether Tishgart's comment Friday was about supporting MPLS VPNs with a new edge solution -- or whether he's really open to using MPLS more pervasively, starting in Europe.

But analysts say that as Sprint expands its network, a new approach seems inevitable. "I wouldn't be surprised if they indeed have to change their position," says Richard Webb of Infonetics Research Inc. "MPLS is more firmly ensconced in Europe than any other continent... When Sprint made the announcement about launching in Europe with non-MPLS IP VPNs, it was met with a wall of apathy and indifference, and skepticism in the press. It was a strange thing for Sprint to do. In Europe, there are very few operators who aren't seriously behind MPLS."

One observer says the issue is really one of marketing. "Sprint can prove its network doesn't need MPLS, but it needs to explain why over and over again," says Brian Washburn, senior analyst at Current Analysis. The carrier suffers from a perceptual disadvantage when it can't fill in that checkmark on customer proposals, even if those customers have fallen for MPLS "hype," Washburn says.

— Mary Jander, Senior Editor, Light Reading

dre 12/4/2012 | 11:45:26 PM
re: Is Sprint Rethinking MPLS? I don't understand the need for MPLS-VPN/AToM or MPLS-TE or even MPLS-COS/GB.

Instead of MPLS-VPN/AToM, use L2TPv3/PWE3.
Instead of MPLS-TE, use ISIS costing.
Instead of MPLS-COS, use DS.
Instead of MPLS-GB, use RSVP-Proxy at the edge, with DS in the core.

Sprint already offers L2TPv3 with Cisco UTI using the GSR platform. Why build out an entirely separate network to offer the basic same sort of technology?

I understand some of benefits for going MPLS, but at this point for Sprint... why would they build out a new network just for MPLS? If you are really going to waste time/resources and resources and even more resources (and even more time) to support the 1M+ lines of code supporting MPLS (especially IOS ST train, which isn't synching across platforms like 12.2S)... then why not do it in your core? That's where you would get the benefit of interworking everything (FR, ATM, Ethernet, HDLC) to MPLS... not on some "extra" network buildout.

I say either: 1) go all the way with MPLS and hire MPLS experts, or 2) stick with the point applications (L2TP/UTI/PWE3, ISIS, DiffServ, RSVP-Proxy with DiffServ) and continue using your specialists that have been doing this stuff for years (and that don't mind using regular S train code without any MPLS features - also known as 1M+ lines of code that breaks everything) with solid code and solid standards you know and trust.

Level-3 and GX have used good concepts that work (their MPLS-VPN offerings are excellent, and their extra network buildouts are well-managed), however it's Sprint that has the strategy... they are doing something different... and it's been a clear advantage for them. Places like C&W have done both MPLS-VPN and UTI/L2TPv3/PWE3 and at a significant cost -- there is obviously no strategy there.
edgehead 12/4/2012 | 11:45:24 PM
re: Is Sprint Rethinking MPLS? I heard that Sprint was using COSN as their MPLS vendor. Makes sense, since they already use them for other IP services...
change_is_good 12/4/2012 | 11:45:19 PM
re: Is Sprint Rethinking MPLS? do you really care what type of plumbing you have as long as it is cheap and reliable? you know - beyond the hype???
optical_man 12/4/2012 | 11:45:19 PM
re: Is Sprint Rethinking MPLS? Author: change_is_good Number: 3
Subject: as a customer... Date: 7/15/2003 9:56:04 PM
do you really care what type of plumbing you have as long as it is cheap and reliable? you know - beyond the hype??? "

change_is_good:
The Police will be at your domicile soon. Under article 1 of the Laws of High Preistesses of Network Command, you have been charged with blasphemy.
To refresh you, the High Priestesses fo Network Command have implemented these powers because common citizens like you do not understand the intricate and complex systems we have built for you.
It is our belief that you also may harbor feelings of satisfaction with other "consumer friendly" yet corruptable vices. You will be notified of our findings and charged the appropriate amount at a later date.

imref 12/4/2012 | 11:44:57 PM
re: Is Sprint Rethinking MPLS? Many of our clients are looking for the following:

- ability of their carriers to support IP-QoS, especially being able to recognize and prioritize based on diffserv markings

- provide any-to-any connectivity at a lower cost than multiple FR or ATM PVCs, primarily to support applications such as collaboration, VoIP, or Video Conferencing

- provide managed Internet gateway services including managed firewalls, thus enabling off-loading of Internet traffic from the WAN link into the data center or HQ site

For all these reasons, MPLS-based services are quite attactive. L2TP can't deliver these types of services AFAIK.

Note something else as well, it is entirely possible for Sprint to deliver RFC2547-based services without introducing MPLS into the core. All that is needed is some sort of tunneling mechanism between the PE routers (e.g. GRE or IPSec). There is a draft that defines how to do this, see: http://www.ietf.org/internet-d... for one example
Greydrive 12/4/2012 | 11:44:53 PM
re: Is Sprint Rethinking MPLS? Disclaimer: I work for Sprint but not for marketing, so this might not be very polished. :)

> - ability of their carriers to support IP-QoS,
especially being able to recognize and prioritize based on diffserv markings

This is easy and doesn't require MPLS at all. It just requires a core network with capacity to handle every incoming packet. QoS is an edge service. Core bandwidth is cheap and it's much easier to upgrade than it is to tag traffic with priorities. That being said, Sprint allows you to do edge QoS if you want. You can prioritize your voice and video while giving SMTP less bandwidth. At the edge, where the T1 is a bottleneck, this makes sense.

> - provide any-to-any connectivity at a lower cost than multiple FR or ATM PVCs, primarily to support applications such as collaboration, VoIP, or Video Conferencing

While not limiting itself to carrying VoIP or video conference traffic, L2TPv3 (a.k.a. UTI) handles this perfectly. L2TPv3 is just like MPLS tunnels in this respsect. All you pay for is two private lines on each side. The backhaul is done over the internet instead of using ATM or FR. To the customer it looks just like any other FR connection.


> - provide managed Internet gateway services including managed firewalls, thus enabling off-loading of Internet traffic from the WAN link into the data center or HQ site

This isn't something even MPLS handles, but it makes sense, which is why every carrier is rolling out products like this. Sprint is using Cosine boxes to handle any provider based firewall requests. Sprint also uses these for network based VPN when security is critical and L2TPv3 wouldn't cut it

I can't say about the RFC2547 thing. I believe we're looking into it for specific uses, but my question is, why don't they just use a frame relay in L2TPv3 tunnel? So the packet would look like this:

IP header:L2TPv3 header (payload: Frame relay header (payload: MPLS header (payload: IP Packet)))

That may not work, or it may be that people just don't like the overhead, but it seems like you could make it ride in L2TPv3 as long as it can ride over frame.

Regarding the article, I don't know anything about what was said, but saying L2TPv3 is faster than MPLS is probably true, but no reason to switch (if you were an MPLS user). A better reason to switch might be that it's easier to configure, and simpler to troubleshoot since it's straight IP.

Even maintenance on an MPLS network might be a challenge. I've never seen a large network with heavy MPLS-TE take a fiber cut, but I'm wondering what happens three or four critical links go down. How does the traffic get rerouted? (That isn't to say MPLS can't handle it, that's just saying I'm ignorant of the possible consequences. Please let me know if it behaves itself :)

Anyway, feel free to correct me on anything I screwed up on. It's been a long day and this probably didn't make much sense. :)


Greydrive
AAL5 12/4/2012 | 11:44:44 PM
re: Is Sprint Rethinking MPLS? Hi Greydrive,

its interesting for a change to get the view from a non-marketing person from a service provider on LR.

I've no disagreement with most of what you said, regarding RFC2547 and Sprint, yes you are looking into it :)

L2TPv3 does not provide an equivalent service as RFC2547, its the equivalent of AToM. With L2TPv3 and AToM you are making a forwarding decision based on L2 lookup to go over a pseudowire, whereas with RFC2547 and its MPLS instantiation MPLS-VPN, the lookup is done on the L3 IP information based on a VPN specific IP routing table, the VPN routing table can be selected using incoming port or source IP address, but there are other methods.

So with L2TPv3/AToM you have point to point L2 connections over an IP/MPLS backbone, and with RFC2547 you have a L3 based service allowing L3 connectivity among remote sites belonging to a VPN.

They solve different problems, legacy FR/ATM services (i.e. where the money is currently), may best be serviced by L2TPv3/AToM if moving to a IP/MPLS backbone. A pure IP environment may best be served by RFC2547. Theres more to it than this simplified explanation.

I have a query regarding this statement you said "L2TPv3 is faster than MPLS is probably true", what do you mean faster, do you mean the performance of L2TPv3 is faster than its equivalent MPLS service? If so I would doubt it, L2TPv3 has more forwarding work to do on imposition or disposition, if there is explicit hardware support for this the penalty would be mitigated, but the hardware platforms I am aware of forward slower for L2TPv3 than AToM.

Another query, you said "A better reason to switch might be that it's easier to configure, and simpler to troubleshoot since it's straight IP.", I am interested to understand why you said this. In my experience an AToM service is fairly easy to debug, as long as it supports some sort of ping functionality for Label Switched Paths.

Regards,

AAL5
sgan201 12/4/2012 | 11:44:41 PM
re: Is Sprint Rethinking MPLS? Hi AAL5,
The discussion need to be separate into edge versus core.
L2TPv3
The edge box is connection aware but the core is basic connectionless IP router

AToM
Both the edge and core is connection oriented with MPLS LSP..

On the edge, both L2TPV3 and AToM may be equivalent. But, in the core, there is substantially different. For L2TPv3, it is basic IP routing. We do not have check individual connection. As long as you can ping rounter A to B, you know it should work..
AToM, the core is connection oriented. You have to ping individual LSP.
Which one is easier??
Correct me if I am wrong..
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE