Tellabs Unveils Vivace Sibling

At the beginning of this year, Tellabs Inc. (Nasdaq: TLAB; Frankfurt: BTLA) didn’t have a product that addressed the market for converged IP/MPLS backbones.

Now it’s got two.

It’s got a multi-service switch/router, the Tellabs 8800, courtesy of its acquisition of Vivace in May (see Tellabs Snags Vivace for $135M). And now it's got the Tellabs 8600, a home-grown platform aimed at the same market, announced today (see Tellabs Unveils Edge Router).

The idea is that these boxes will work together in carrier networks. The new 8600 is a lower-capacity (42-Gbit/s) edge router optimized for providing Layer 2 and 3 MPLS VPNs in access and regional networks. The 8800 is a bigger beast, designed to sit deeper in the network. It has a capacity of 160 Gbit/s, which can scale to 2.5 Tbit/s, according to Tellabs. It boasts some functions not found on the 8600, aimed at enabling carriers to migrate legacy Frame Relay and ATM services onto IP/MPLS backbones.

In a Light Reading Webinar on IP/MPLS backbones yesterday, Paymon Mogharabi, product line manager for the Tellabs 8800, contended that the box's flow-based multiservice switching was the only surefire way of guaranteeing quality of service for legacy services – a critical issue for carriers.

Another speaker in the Webinar, Azhar Sayeed, product line manager in the IOS division of Cisco Systems Inc. (Nasdaq: CSCO), begged to differ. He said hardware improvements now mean there's little to choose between multiservice switches and the latest edge routers in this regard.

Tellabs' acquisition of Vivace had a lot to do with the development of the 8600 in its R&D facility in Finland. During development work, Tellabs realized it would need a high-capacity box, and along came Vivace with just such an animal, and a similar vision of how converged IP/MPLS backbones would evolve. "Everything resonated with how we saw things," says Mika Heikkinen, vice president of Tellabs Managed Access Solutions and general manager of Tellabs Finland.

Heikkinen says the combination of the 8600 and 8800 "will kill the complexity of MPLS networks." Tellabs will bring the two boxes under the control of a common management system, so that carriers can provision services from a central console.

The 8600 is already in trials with TeliaSonera AB (Nasdaq: TLSN) and will ship in the first half of next year. A U.S. launch is planned in a couple of months' time, according to Mike Kazban, Tellabs' vice president of marketing for advanced data products.

— Peter Heywood, Founding Editor, Light Reading
materialgirl 12/4/2012 | 11:23:32 PM
re: Tellabs Unveils Vivace Sibling Everybody seems to have accepted the idea of service providers moving to MPLS/IP cores with multi-service switches used for access. However, the debate rages between L2 and L3 VPNs. It appears as though L2 VPNs are more of a hassle, but are somehow more "robust", while L3 VPNs are easier to set up, but more "risky" (in terms of either security or service levels).

Is this a case of hardware catching up with service demands, ie faster chips will allow for higher abstraction of faster data flows (the CSCO arguement), or do we still need to do custom bit twiddling to get the flows we need? Do we need full packet inspection at a 10Gbps line speed?

Do static L2 VPNs become the norm between fixed sites, with L3 VPNs used for access by small branches and road warriers? Do legacy services like Frame Relay or ATM need L2 VPNs for some reason (latency for instance)? What about storage area networks? Perhaps a FICON or FCI network used for synchronous backup needs L2 while an iSCSI network used for periodic snapshots could use L3. Does a vendor need to offer both, as TLAB seems to be doing?
AAL5 12/4/2012 | 11:23:26 PM
re: Tellabs Unveils Vivace Sibling Materialgirl,

L2 VPNs do not have to be more of a hassle, is your statement because of the need to configure multiple connections between peers?

If L2VPNs are used with a auto-discovery mechanism, implemented for example using BGP then VPN membership can be configured on individual boxes and the appropriate pseudo-wires automatically setup, making provisioning a lot easier.

You asked "Do we need full packet inspection at a 10Gbps line speed", well not when providing a L2VPN service, if offering a L3 based service you will want to dig into the packet to do L3-L4 flow based features such as ACLs, policing based on L3 port number etc. This is currently achievable at 10Gbs rates.

You asked " Do legacy services like Frame Relay or ATM need L2 VPNs for some reason (latency for instance)?".

The decision to provide L2 vs L3 VPNs is more customer focused. Currently most service providers provide either a FR or ATM service to the customer, the service is a L2 service, the customer is responsible for managing their L3 routing information and any L3 protocol can be sent via the L2 service. AToM and L2TP may be used to replace this type of service if going over an MPLS or IP core.

L3 VPNs do not replace any existing service that I am aware of, but try to add value by the service provider managing the VRF L3 routing information. Some people view this as a good or bad thing.

flush_meat 12/4/2012 | 11:23:16 PM
re: Tellabs Unveils Vivace Sibling AAL5,

Well explained answer. Which one is more popular
on the access side? ATM or Frame Relay? I guess ATM.

big daddy 12/4/2012 | 11:23:14 PM
re: Tellabs Unveils Vivace Sibling I would agree - ATM.
materialgirl 12/4/2012 | 11:23:13 PM
re: Tellabs Unveils Vivace Sibling AAL5: The hassle (as I understand it) in managing L2 VPNs is in the labor to configure all of the clients, versus just using a standard browser. Over worked IT departments need to minimize this sort of effort, limiting the number of clients to static points.
Road Trip 12/4/2012 | 11:23:13 PM
re: Tellabs Unveils Vivace Sibling I agree with Big Daddy - ATM.
flush_meat 12/4/2012 | 11:23:11 PM
re: Tellabs Unveils Vivace Sibling Which mode is common for ATM L2 VPN? I would
again guess that ATM AAL5 mode since the overhead
is less. But, one can support ATM cells as well,
right? If so, when do we need it? What about OAM?
AAL5 12/4/2012 | 11:23:11 PM
re: Tellabs Unveils Vivace Sibling Agreed ATM would be more popular, but it is often used to provide a Frame Relay service to the customer.


with L2VPN auto-discovery all you need to do is configure VPN ID membership and the pseudo-wires will be created for you without having to explicitly configure N*N tunnels.

So the configuration model is similar to L3VPN, but the mechanisms used to forward are different.

A similar configuration mechanism can also be used for VPLS, and the N*N tunnels can be automatically provisioned after configuring VPLS VPN membership.

AAL5 12/4/2012 | 11:23:08 PM
re: Tellabs Unveils Vivace Sibling Regarding which mode is more common for ATM L2 VPN, Service Providers are only starting to deploy or are in the stages of planning to deploy L2VPN services over a IP or MPLS core.

It will depend on the original service agreement with the customer i.e. if they are providing a Cell based service or AAL5. My impressions are that Cell mode is a more likely deployment, but its early days.

The inefficency of single cell ATMoMPLS or ATMoL2TP can be mitigated by implementing cell packing, with appropriate jitter/packet size and timeout parameters.

OAM can be handled in two ways one is to terminate certain OAM cells, or the other is to implement pass through mode where they are sent end to end. This would depend on the OAM cell types and application.


Sign In