The Death & Life of Sonet/SDH 597076

Le SDH est mort... Vive le SDH!

November 14, 2003

6 Min Read
The Death & Life of Sonet/SDH

When carriers and vendors talk about the future of Sonet and SDH, one obvious theme is almost universal: Sonet and SDH are here to stay, because the installed base is just too big and it’s already paid for. Carriers will simply add data-aware standards and products to their old Sonet/SDH networks to offer Ethernet services with Sonet/SDH reliability.

But the six months of research it took to create the latest Heavy Reading report – The Future of Sonet/SDH – revealed an amazing and unexpected twist on that theme: Third-generation Sonet/SDH isn’t really about preserving the legacy network – it’s about destroying that legacy.

After talking with carriers and vendors for six months, I’m more and more convinced that the choices carriers are making today about their Sonet or SDH networks will be as far-reaching as any they have ever made, with implications for every telecom hardware and software vendor in the market today.

Some background will help to show why. We’re actually starting into the third generation of Sonet/SDH. The first generation was the add/drop multiplexer, based on the original set of standards for SDH developed back in the 1980s. The second generation, a.k.a. next-gen Sonet/SDH, showed up about five years ago, transforming the ADM into a Sonet switch, with mechanisms for mapping Ethernet to Sonet or for integrating ATM switching for data services aggregation.

Third-generation Sonet/SDH takes this a big leap further, using a set of standards-based tools – GFP (Generic Framing Procedure), VCAT (virtual concatenation), LCAS (Link Capacity Adjustment Scheme), and, in some cases, Resilient Packet Ring Technology – to build a wide variety of data-aware Sonet platforms that aggregate, switch, and transport just about any kind of traffic a carrier can imagine over its legacy Sonet/SDH network.

This gets to the heart of the reason for third-gen Sonet/SDH: transforming a legacy network from the outside in, as cost-effectively as possible. It makes perfect sense, and in most cases it’s been working. But in doing the research for the report, I began to wonder whether the logic of next-gen Sonet/SDH held up. Is the evolution of Sonet/SDH as simple as putting multiservice provisioning platforms (MSPPs) in central offices and watching the revenues rise while the opex falls? Is next-gen Sonet really about preserving the installed base?

I now believe the answer to that question is “no” – but that’s a good thing. Here’s why:

  • 1) The marriage of Ethernet and Sonet/SDH is official, and virtual concatenation is in the vows. Ethernet-over-Sonet services will nearly always use VCAT, which makes this perhaps the first service ever in which the transmission facility is so tightly coupled with the data link layer. They are in fact inseparable. No matter how you look at it, Ethernet single-handedly will be responsible for breaking down the divisions between transmission and service networks. This inevitably leads to converged platforms for supporting Ethernet over Sonet.

    2) The arrival of Ethernet over Sonet leads to network element evolution: The MSPP changes when RPR is added to support efficient transport of packet services in physical or extended rings. This new MSPP begets the MSSP (multiservice switching platform), a new kind of metro core system designed to bring the digital crossconnect and multiservice switch together. The MSSP aggregates traffic from the access network and represents a point of Sonet services creation, management, and extension. The MSSP begets yet another new product category, the MSTP (multiservice transport platform), which binds metro DWDM and interoffice transport muxes together to support a mix of well-aggregated Sonet/SDH services as well as wavelength services. Are these God boxes? Not quite, but they do require that one system participate in the management of transport bandwidth as well as service aggregation and switching. (The bugaboo for these devices is routing, incidentally, but if they can stay away from trying to implement BGP they’ll be safe from scorn.)

    3) Network element evolution leads to management and OSS evolution. GMPLS (generalized multiprotocol label switching) already is hiding out in a number of next-gen Sonet boxes, supporting end-to-end provisioning, link-state monitoring, and network topology discovery. These vendor-specific implementations of GMPLS will someday give way to independent GMPLS implementations built by the carriers themselves or provided by third-party vendors.

    4) This brings us to MPLS, which begins to surface in the transmission network as an enhanced means of network and services management. But the potential for MPLS to insinuate itself much farther into Sonet/SDH networks is already in place, thanks to GFP. Today, GFP’s big advantage is that it is a better mapping/framing solution than HDLC (High-level Data Link Control), which means we can kiss the packet-over-Sonet/SDH model goodbye. But in the future, GFP will do more than traffic adaptation – it will converge whole networks by providing a mechanism for mapping MPLS flows directly into Sonet/SDH channels and the MPLS control plane into the overhead of those channels.

    5) Which brings us to... a whole new network. If one can have an epiphany thinking about telecom networks, then this third-gen Sonet/SDH business is a place to have one. I started my research thinking that third-gen Sonet was about preserving the installed base, but I ended up convinced that the opposite is true. For every MSPP a carrier puts in its network, it takes another step down the path of transforming the network, not preserving it. MSPPs alone do not make carriers money. In fact, they reveal how difficult it is to make money from a network originally impressed by 128-kbit/s services. MSPPs are just the start; it’s what comes after that truly makes the difference in how quickly a carrier can move toward profitability with Sonet/SDH services.

It’s no wonder the designers of the first next-gen Sonet platform, the Cerent 454, purposefully chose a product numbering scheme borrowed from Chevrolet muscle cars of the 1960s. If you’ve ever owned a big-block 67 Chevelle, you know that adding a hydraulic camshaft inevitably leads to adding stainless valves and rocker arms, which leads to an aluminum manifold, which leads to aluminum heads, headers, and braided hoses… and you haven’t even touched the interior yet. In a couple of years you no longer have your old car – you have something that looks just like it, built from “next-gen” after-market parts, occupying the same familiar space, but performing in a way that makes your hair stand on end and your neighbors resentful, envious, and deaf.

Anyway, back to the report from Heavy Reading. Here’s the thesis in a nutshell: this an incredibly critical time in network evolution history – because the choice to go with next-gen Sonet will determine every subsequent choice for years; it means the operator will rebuild the network in its own image but with different goals in mind and a newer box of tools.

— Scott Clavenna, Chief Analyst, Heavy Reading

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like