x
Optical/IP

Interworking Tops Alliance 'To Do' List

Carriers are pinched. They want to support growing demand for packet-based services, and they're under pressure to implement Multiprotocol Label Switching (MPLS) on their networks. At the same time, they're being asked by business customers to sustain and even expand their so-called legacy offerings.

So it's no surprise that over 200 attendees at last month's Supercomm tradeshow in Atlanta said the MPLS/Frame Relay Alliance should devote its energies to finding ways to interwork -- making Frame Relay, Asynchronous Transfer Mode (ATM), and Ethernet services work together via MPLS.

The survey yielded the following list of items for the group to consider (1 being the most common response, 5 the least):


    1. Multi-class traffic engineering
    2. Multi-provider, multi-area L2 VPNs
    3. Inter-area, inter-provider BGP/MPLS IP VPNs
    4. Fast restoration
    5. VPLS

The above items aren't demands for specs, but instead are listed as areas where the alliance needs to create conformance and interoperability tests and demonstrations. "We're filling in the spaces, chosing how standards can be made to interwork," says Gary Leonard, who co-chairs marketing, awareness, and education for the Alliance and works at Riverstone Networks Inc. (Nasdaq: RSTN).

Interestingly, all respondents listed multi-class traffic engineering as top priority, but other priorities were more controversial.

For instance, service providers responding to the survey, comprising 38 percent of the 245 respondants, said VPLS (virtual private LAN service) should come third in line, after multi-class traffic engineering and multi-provider, multi-area L2 VPNs. But VPLS wound up in last place because of responses by systems vendors (31 percent of all respondents), consultants (13 percent), components vendors (3 percent), and others.

VPLS is slowly gathering momentum among service providers and their suppliers, even though the survey indicates it may be simmering on the back burner (see VPLS: The Future of VPNs? and Virtual Private LAN Service).

The survey also produced a list of applications and deployment goals for the Alliance to consider. Again, these aren't specs, but general ways carriers can go about putting standards into practice in their networks:



    1. ATM/Frame Relay/Ethernet any-to-any interworking
    2. FR-MPLS interworking
    3. MPLS-PNNI interworking
    4. MPLS user-network interface specification
    5. Voice over MPLS
    6. Proxy admission control for MPLS networks

Carriers responding to the survey said MPLS-PNNI interworking should top applications and deployment priorities. This seems in keeping with service provider wishes to smoothly migrate ATM-based core networks to MPLS. Again, though, the service provider vote was watered down by other respondents.

Regardless, it's clear that members of the Alliance, formed earlier this year by the union of the MPLS Forum and Frame Relay Alliance (see Forums Forge Alliance), see interworking as key to their future (see Interworking).

Members of the Alliance will use the input in creating its ongoing agenda, starting with the quarterly meeting set for July 9-10 in Vienna, Va. The group plans to discuss ATM/Frame Relay/Ethernet interworking via MPLS, along with testing of multi-class traffic engineering, SLAs for MPLS networks, and Layers 2 and 3 VPN interworking.

To view the results online, click here.— Mary Jander, Senior Editor, Light Reading

BobbyMax 12/4/2012 | 11:48:52 PM
re: Interworking Tops Alliance 'To Do' List Many service providers have elected not to implement MPLS in their network. Sprint is a prime example of this. By not implementing MPLS, they have reduced cost and allso eliminated questionable benefits arising from deployment of MPLS. There are many alternatives to MPLS and some nmay even be a little bit cheaper.

At a time when the income is down, service providers cannot afford to spend millions of dollars on a questionable technology

Many service providers such as SBC and Bell South have chosen to implements in their backbone networks. The scalability of MPLS have been questioned by many service providers. The providers do not have expertise to deal with MPLS if goes wrong in the network.
gea 12/4/2012 | 11:48:50 PM
re: Interworking Tops Alliance 'To Do' List BobbyMax:

All your base are belong to us.
metro_ether_man 12/4/2012 | 11:48:48 PM
re: Interworking Tops Alliance 'To Do' List Read This!!!!
I think it sets the stage for
things to come in the not so distant future.

http://www3.sprint.com/PR/CDA/...
materialgirl 12/4/2012 | 11:48:45 PM
re: Interworking Tops Alliance 'To Do' List Is Sprint hooked on ATM? That costly ATM-based ION network is barely cold in its grave when they sign up Nortel for their "packet" network. Isn't Nortel's Passport product based on ATM and not IP? What have they gained here?
deckchairs 12/4/2012 | 11:48:44 PM
re: Interworking Tops Alliance 'To Do' List The last I heard, Sprint would only consider VoATM on their "packetized" voice network for reliability reasons - and even then they only wanted to run traffic using AAL5/CES. The network was architected to use the existing SS7 infrastructure for end-to-end voice call control, not Q.291, partially because SS7 is a highly trusted/familiar protocol and partially because its required for Feature Group D LEC handoff. Data traffic could then be integrated into the ATM network, and not run as a separate overlay.

I don't see where MPLS adds value to this architecture. Is there a significant benefit to replacing ATM with MPLS if you're running CES, using SS7 for call control and some kind of media gateway control protocol (e.g. Megaco) for the switches? I can see the argument to run the data traffic over MPLS, but data becomes an overlay network again.

deckchairs
materialgirl 12/4/2012 | 11:48:42 PM
re: Interworking Tops Alliance 'To Do' List THen what is the difference between what Sprint is doing now and what they did with ION? Was ION not a packetized ATM network? Could they even be using the same gear?
deckchairs 12/4/2012 | 11:47:54 PM
re: Interworking Tops Alliance 'To Do' List Well, I little detailed information on ION. ION seemed like a project to merge voice traffic into the overlay data network, whereas the Nortel project tried to merge data traffic into the core voice network. I never understood how ION was going to route and *bill* voice calls.

A keystone to this project is integration with Sprint's SS7 network, including Signalling Control Point database access for number lookup and card authorization. I never saw that with ION - but, like I said, I didn't have much knowledge of it.

There may also have been some corporate politics involved. Both these projects really gained momentum in 1998-99 when the Internet was going to replace telephones. These may have been competing techologies within Sprint.

deckchairs
alchemy 12/4/2012 | 11:47:50 PM
re: Interworking Tops Alliance 'To Do' List deckchairs writes:
The network was architected to use the existing SS7 infrastructure for end-to-end voice call control, not Q.291, partially because SS7 is a highly trusted/familiar protocol and partially because its required for Feature Group D LEC handoff.

Funny how no matter how much things change, they still stay the same. In VoIP networks, the preferred method for signaling these days is SIP-T... tunneling SS#7 ISUP binaries in MIME format inside SIP messages. The IETF people have 500 draft specs trying to re-invent this but it's not clear that anyone who is truly serious about interworking will ever migrate away from SS#7.

I don't see where MPLS adds value to this architecture. Is there a significant benefit to replacing ATM with MPLS if you're running CES, using SS7 for call control and some kind of media gateway control protocol (e.g. Megaco) for the switches? I can see the argument to run the data traffic over MPLS, but data becomes an overlay network again.

But the promise is that some day, you'll be able to get ultra-reliable pipes out of MPLS so you won't need that archaic old five 9's telecom signaling network. Cisco will rule the known universe. Of course, SS#7 works and MPLS with fast protection switching is merely a science experiment...
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE