x
Optical/IP

Zarlink Chip Targets PWE3

Zarlink Semiconductor Inc. (NYSE/Toronto: ZL) has produced what officials say is the first purely Ethernet chip for circuit emulation, adding to a growing pool of silicon targeting the emerging standard.

The Internet Engineering Task Force (IETF)'s Pseudo Wire Emulation Edge to Edge (PWE3) proposals would allow the creation of virtual LAN connections across a carrier's IP or MPLS network. An Ethernet version would let carriers apply this concept to corporate LAN traffic, creating "pseudo-wire" connections that cross the network core (see Zarlink Intros Pseudo-Wire Processor).

Startup Redux Communications Ltd. already has a PWE3 chip on the market, but Zarlink is calling itself "first" because the ZL50130 is hard-wired for Ethernet PWE3. By contrast, Redux's RS-160 is programmable, able to handle multiple variants of the standard.

PWE3 is a broad standard whose variations can be lumped into two camps, a TDM side and an Ethernet side. Rather than tackle both sides at once, as Redux did, Zarlink opted to create separate, hard-wired chips. (The TDM variant was previously released.)

The PWE3 standard isn't completed, but pre-standard deployments have been popping up, prompting companies to begin marketing off-the-shelf chips.

"People are doing it, but on an ad hoc basis," says Jeremy Lewis, product line marketing manager for Zarlink's packet processing group. "We see our Tier 1 customers implementing the draft with solutions that are piecemeal -- FPGAs and the like."

Other companies developing PWE3 chips include RAD Data Communications Ltd. and startup Lycium Networks Ltd. Both appear to be concentrating more on the TDM side (see Lycium: It's All in the Timing and Redux Revisits RAD).

— Craig Matsumoto, Senior Editor, Light Reading

fiberous 12/4/2012 | 11:14:38 PM
re: Zarlink Chip Targets PWE3 What is the value of circuit emulating TDM flows over Ethernet?
TDM implies a constant bit rate - so, there is no
way it contributes to any statistical multiplexing
advatantage.
If clock is recovered for arriving frames and
Ethernet discards frames that have errors, even if
the frame's headrer is not corrupted but only
the payload - hence one frame loss will result in
ESF errors.
What is the big deal here?

Is this a solution desperately looking for a
problem, or a psuedo problem?
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE