Comms chips

Multilink Makes Sonet Flexible

Components vendor Multilink Technology Corp. (Nasdaq: MLTC) is the latest vendor to jump on the next-gen Sonet bandwagon.

Tomorrow Multilink is planning to announce the first chip in what it calls its "intelligent edge" portfolio. Part number MTC6210 is an OC192 Sonet framer chip offering a bundle of new-age Sonet features, including virtual concatenation, GFP (generic framing procedure), LAPS (link access protocol-SDH), and LCAS (link capacity adjustment scheme).

Acronym overload? In a nutshell, all these protocols aim to provide more efficient ways of transporting packet-based data over Sonet. GFP is the latest way of encapsulating Ethernet and other protocols for transportation over a Sonet-based infrastructure. LAPS does the same thing for SDH.

Virtual concatenation is a technique for "right-sizing" Sonet channels so they can carry data traffic without wasting bandwidth -- by grouping an arbitrary number of STS1 (51.8 Mbit/s) units together. (For a more detailed explanation, see PMC Pushes Sonet Silicon.)

LCAS is the really cool bit. It allows hitless switching of the virtually concatenated groups. In other words, the size of the data pipe assigned to any one customer can be changed at any time without affecting the data carried on any of the other channels. With this ability, a service provider could assign different bandwidths to the same customer at different times of day, giving them extra bandwidth for nighttime backups, for example. This is a far cry from today's Sonet networks where provisioning some types of circuit can take weeks or even months.

All this is a foray into new territory for Multilink, which previously didn't have any Sonet-specific chips in its portfolio. Its traditional product lineup includes mux/demux chips, modulator drivers, forward error correction (FEC) chips, and optical modules.

According to Tom Spencer, Multilink's senior marketing manager for intelligent edge products, the company hoped that it could leapfrog its competitors by entering the next-generation Sonet market at OC192 (10 Gbit/s). To date, the key players in this market -- including Agere Systems (NYSE: AGR), Agilent Technologies Inc. (NYSE: A), and PMC-Sierra Inc. (Nasdaq: PMCS) -- only offer OC48 (2.5 Gbit/s) products (see Agilent Boosts Ethernet-Over-Sonet).

Although Multilink appears to have fulfilled his ambition as the first company to announce an OC192 part, it will be four or five months before the product starts shipping. So it's possible that other companies, if their policy is to ship products before making announcements, could get to market first. All the vendors with OC48 parts are likely to be developing OC192.

Nevertheless, Multilink reckons that its chip will stand out in a crowd. No two virtual concatenation framers are alike, Spencer says, and customer contracts live or die by the details.

Multilink has one of the first virtual concatenation parts to support the SPI4.2 interface, which is becoming the de facto standard for interconnecting with network processors on the system side. That makes it more likely that it can form glueless connections to chips from other vendors.

It's also one of the first chips to support LCAS. The only other announced product that supports LCAS runs at OC3 (155 Mbit/s) -- that's from TranSwitch Corp. (Nasdaq: TXCC) (see TranSwitch Creates a Hybrid).

However, although LCAS sounds pretty wonderful, the standard is still immature and won't be adopted in real-world networks for some time. "Some aspects [of the standard] are ambiguous," Spencer admits. "They could be interpreted in different ways, which could end up making interoperability an issue."

The network infrastructure isn't completely ready to support LCAS, says Jim Shupenis, Agilent's strategic business development manager. It can cope with point-to-point LCAS but cannot handle situations where the signal is split and sent down different routes to the same destination. Agilent is also working on LCAS for its Sonet product line but won't say when it will be ready.

— Pauline Rigby, Senior Editor, Light Reading
ajo2 12/4/2012 | 10:20:12 PM
re: Multilink Makes Sonet Flexible > But in the end, Multilink didn't manage it. The
> company delayed its announcement for a few
> weeks, and, in the meantime, Cypress
> Semiconductor Corp. announced an OC192 virtual
> concatenation framer (see Cypress Intros OC-192 Framer ).

The OC-48 product from Cypress has virtual concatenation, but no where in their publicly available data does it say that their OC-192 product does virtual concatenation. Nor GFP.
Huub_van_Helvoort 12/4/2012 | 10:20:11 PM
re: Multilink Makes Sonet Flexible If Spencer from Multilink claims this, why were there no contributions from Multiling in the last T1X1.5 and ITU-T SG15 meetings to remove these ambiguities? Representatives from Multilink were present at those meetings.

Regards, Huub.
Huub_van_Helvoort 12/4/2012 | 10:20:11 PM
re: Multilink Makes Sonet Flexible GFP and LAPS are two completely different means of transporting data over a synchronous network.
(the statement GFP is for SONET and LAPS is for SDH is totally wrong).
Both provide mapping of variable bitrate signals (packets) into a constant bitrate signal like SDH, SONET, OTN.
Both are ITU-T standards, G.7041 resp. X.86.
GFP is adopted by ANSI T1X1 as a standard.

Regards, Huub.
Pauline Rigby 12/4/2012 | 10:20:11 PM
re: Multilink Makes Sonet Flexible ajo2, I agree with you. I made a mistake about the OC192 part from Cypress, so I've corrected the story.

[email protected]
lord_vader 12/4/2012 | 10:20:11 PM
re: Multilink Makes Sonet Flexible they don't know the difference probably ...
Huub_van_Helvoort 12/4/2012 | 10:20:10 PM
re: Multilink Makes Sonet Flexible One of the prerequisites for the introduction of Virtual Concatenation (VCAT), and LCAS too because it is an extention to VCAT, was that the network should not be aware that the individual VCs/STSs transported belong to a VCAT (+LCAS) signal.
Only the source and sink are VCAT(+LCAS) aware.
The operator, when setting up a path, has to be aware of any physical path difference (5ms per 1000 km) to stay within the limits of the acceptable differential delay. So it is not mandatory for the VCs/STSs to follow the same physical route, not even initially as claimed by Mr. Shupeneis.

Regards, Huub.
gbennett 12/4/2012 | 10:20:10 PM
re: Multilink Makes Sonet Flexible Hi Pauline,

LCAS *can* do hitless adjustment in a planned change scenario, such as the time-of-day scheme you mentioned.

However, in a link failure scenario, LCAS (and indeed any other signalling protocol) can't promise hitless operation.

LCAS currently assumes that a SONET/SDH trail has already been set up. LCAS can't create a new timeslot from scratch, ie. it can't "reroute" a trail over a different physical fibre or wavelength. This is why it's an "Adjustment" scheme.

LCAS in conjunction with GMPLS *could* do trail rerouting, for example. but the addition of GMPLS protocols still won't make that rerouting hitless.

Note that LCAS goes hand in hand with Virtual Concatenation. For example, let's say you were providing a Fast Ethernet link with an STS-1-2v (ie. two STS-1's, virtually concatenated), and each individual STS-1 is routed over separate paths on the SONET network (this is a feature of Virtual Concatenation). If one of the individual paths fails (and is not protected), LCAS would allow the end points of the service to be notified of the reduced bandwidth. This isn't a hitless operation, but it should happen fast enough for most data services to stay up.

telecom 12/4/2012 | 10:20:09 PM
re: Multilink Makes Sonet Flexible concatenation + LCAS seem to be attractive within the limitations of SONET/SDH infrastrucutre. An existing SONET path of STS-n or STS-nc capacity can be increased or decreased using LCAS, but the additional STS-1s or STS-3cs that will be added need to be setup before LCAS starts to add them to the existing circuit in a hitless manner. NMS, GMPLS or even mannually one can setup the additional STS-1s if GMPLS is not going to materialize soon and stays only in papers.

What is not clear to me is the details on both
contiguous and virtual concatenation in terms a new path layer that is mapping ethernet services into mSTS-1s or mSTS-3cs. At the receiver, which receiver STS-1s with different network paths, it is reassembly of individual STS frames. It sounds to me that silicon required to do this might as well be used to achieve the same end to end bandwidth pipe wihtout using fixed STS-1s and the associated complexities. The multi frame synchronization, in the event of loss of synchronization, there will few ms (wors cast 256ms?) before re-sync is established. Also what is the propogation delay between the slowest STS-1 and the fasted STS-1? The receiver need to buffer so many STS-1 frames in order to complete the reassebly. This is like we are entering into ATM AAL1/AAl5 reassembly. Why not use ATM/IP directly? If 5 STS-1s are used to setup 250 Mbps pipe , the overhead is about 7% (1,2,3,4,30,59 columns) plus the mapping complexity.

But i agree that within the limitations of SONET/SDH , concatenation and the current version of LCAS provide some way for optimally mapping Ethernet services.

Will there ever be a model where the end to end ethernet pipe is tapped at places other than ingress and egress? If so, will there be need to support 802.11q.

Will there be any need for intermediate NEs to be aware of the end-to-end path.

Will there be need to inject traffic into inidividual STS-1s at intermediate NEs?

Sign In