Despite plenty of heckling from competitors and analysts alike, a contentious standards process that seemed stalled at many turns, and very fragmented market successes (China greenfields, some MSOs, AT&T Business in Manhattan, Bell Canada, KDDI, WorldCom, and a few carriers in Europe), Resilient Packet Ring systems have continued to sell well enough to keep the dream alive through the telecom cataclysm and its possible recovery (see Who Knew? Big Carriers Like RPR).

But like a new species emerging out of a nuclear winter, RPR is morphing to suit the current ecology. You will not likely see the term RPR very often anymore, but instead “Packet ADM” will be used to encompass the new model of packet-ring-based networking. Those startups still singing the RPR tune – including Appian Communications Inc., Coriolis Networks Inc. (sort of), Corrigent Systems Inc., Lantern Communications Inc., Luminous Networks Inc., and Turin Networks Inc. – are all beginning to talk about how RPR is just part of the solution, not the whole of it.

Why go about repositioning RPR? Well, the acronym has gotten rather sullied over the past few years, and it’s not a bad time to restate just what it is and how it can be used within a metro solution.

The mudslinging started early on. Messing with the Ethernet MAC (media access control) raised plenty of ire, and early proprietary schemes from Cisco Systems Inc. (Nasdaq: CSCO) and Nortel Networks Corp. (NYSE/Toronto: NT) so dominated the landscape that most wondered if a standard could every truly emerge with such Goliaths at each other’s throats (see RPR: RIP? and RPR: Deadlock Ahead?).

RPR startups made lots of noise in favor of RPR, but some were too quick to say RPR would do away with Sonet entirely, spelling the useful end of circuit-switched networks in the metro. In the face of CLEC collapses and ILEC triumphs, the staying power of Sonet was assured, and this early notion of the pure-packet ring was dismissed as a relic of the bubble.

The technical benefits of Resilient Packet Ring Technology were always questioned as well, with many saying the values of spatial reuse, statistical multiplexing across the ring, and per-flow protection worked on paper but did not reflect the realities of metro architectures and services. Put RPR in a real telecom carrier network and that statistical muxing on a two-node ring didn’t offer much efficiency. Bandwidth reuse didn’t add much benefit if most customers wanted the highest level of protection per service. And RPR’s limitation to a single ring meant MPLS had to be employed to extend its benefits across whole networks – and that remains a scary proposition when trying to land an incumbent carrier.

But RPR vendors remain undaunted. The answer, it appears, is to talk, not about RPR, but about “packetized transport.” It has a proper ring to it, and as most of the major ILECs in the U.S. begin to embark on rolling out new transparent LAN services, Ethernet private lines, and other switched packet services, the Packet ADM (add/drop multiplexer), at least conceptually, has its merits.

So what constitutes a Packet ADM? It depends on whom you ask. Corrigent is perhaps the most vocal proponent of the concept, followed by Luminous, Lantern, and Coriolis. The main ingredients include the following:

With these ingredients in place, you end up with a metro system that looks in most respects like a Sonet ADM on the outside, yet is based entirely on packets and MPLS on the inside. Every client signal entering the system is packetized, encapsulated, and mapped to a specific Sonet channel for transport onto the ring. RPR takes care of the class of service management, while MPLS runs the show, providing traffic engineering, customer segregation, end-to-end automatic provisioning, and monitoring, all while carrying each service as a pseudowire.

It all sounds rather complex at first blush. Here’s a box, marketed to an ILEC transport group, that is in fact a pure packet system, with integrated packet handling that can run the gamut from simple oversubscribed Ethernet virtual private lines, to Frame Relay transport with idle frame suppression.

The pitch is straightforward: For carriers to ever make a profit on data services they need to get bandwidth utilization under control. A Packet ADM attacks this from many angles: Oversubscribe the service when possible, reuse protection bandwidth and available spans on the ring when possible, and suppress idle frames natively so only frames carrying real customer data get transported along the ring.

You can envision many heads being scratched in the room while pseudowires are explained to folks who have only worked with real wires for twenty years.

But there is some elegance to the concept if you believe that bandwidth efficiency represents the key difference between profitable and unprofitable data services. If you don’t, then the added complexity of a Packet ADM may just offset any efficiency gains in the network.

I’ve talked to carriers in the past month about this and found equal numbers on either side of the debate. It almost always comes down to the dominant service they are offering (if it’s DS3s then the Packet ADM doesn’t do much for them), and their metro network architectures (lots of two-node rings and a well-utilized BLSR interoffice ring sort of kills the RPR benefits as well).

All told, the repackaging of RPR into a Packet ADM makes plenty of sense, but time will tell if carriers take the bait. There was a time when bandwidth efficiency was seen as folly in the face of fiber-to-everything networks, but times have certainly changed. Capex and opex are both well-worn watchwords in today’s networks, and a Packet ADM addresses them both adequately by not just increasing the number of customers on any given metro ring, but by reducing the number of ports required on edge and core data switches and routers. At the same time, it offers up the recurring panacea of a unified control plane and service management.

We’ve heard from AT&T that this is just what they want (see AT&T’s New Gods). We’ll have to wait and see whether they bite soon enough to keep the Packet ADM alive. Or else another name for RPR will have to be invented.

— Scott Clavenna, Director of Research, Light Reading