RPR’s New Guise: The Packet ADM

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:
  • Sonet Physical Layer provides OAM capabilities, clock distribution, and interoperability with legacy networks; optional GFP (Generic Framing Procedure) mapping and framing, providing a standardized means of mapping packet flows into Sonet/SDH; virtual concatenation to support many virtual RPR rings on a single physical fiber ring; and LCAS to support hitless resizing of those virtual rings.

  • RPR MAC layer, provides access control to the shared packet ring. The physical fiber ring is transformed logically into a distributed packet switch backplane, thus capable of supporting statistical multiplexing across all ports on each node and across the entire ring. RPR’s fairness algorithm ensures that flows with highest priorities (and therefore customers paying the highest price) get preferred access to available bandwidth and protection.

  • Multiprotocol Label Switching (MPLS) provides signaling, traffic engineering, and encapsulation of customer traffic into “pseudowires,” an IETF-defined means of emulating point-to-point services over IP or MPLS. This can include both Layer 2 traffic (Ethernet, Frame Relay, ATM) or even Layer 1 traffic, such as TDM private lines.
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

Page 1 / 3   >   >>
sir-wish-pro-wide-her 12/5/2012 | 12:06:51 AM
re: RPR’s New Guise: The Packet ADM In the figure provided in the article, anyone
know why EoS itself wouldn't be a preferred
way to go for mac layer rather than rpr?

gea 12/5/2012 | 12:06:50 AM
re: RPR’s New Guise: The Packet ADM Actually, this sounds to me like it was a fairly inevitable convergence of packet and circuit-centric technologies.

In the scheme of the so called "Packet ADM" I wonder what happens when there's no SONET ciruits at all, just a big OC-Nc pipe with packets in it. Does it resemble traditional RPR? Does it end up being cheaper than somewhat equivalent SONET solutions?

At Jedai we originally tried to create something similar: a box that could handle DS3 and STS-Nc circuits, but that could "grab" the remaining unassigned bandwidth for a big, shared MPLS-based packet pipe. (We wanted DS1s to be circuit emulated within the packet pipe.)

We also published some papers that pretty much predicted this, so its a Pyhrric vindication of sorts.
sevenbrooks 12/5/2012 | 12:06:49 AM
re: RPR’s New Guise: The Packet ADM
Ethernet over SONET (or SDH) will be used for high bandwitdh drops to customer (like say direct GigEs).

There will be a significant number of customers who will only want a fraction of the Gigabit interface or often a smaller interface.

I would say the jury is out on whether a packet aggregation box will sit in infront of a Layer 1 transport or a Layer 2 transport box will exist.

wass 12/5/2012 | 12:06:43 AM
re: RPR’s New Guise: The Packet ADM I personally think that RPR will eventually revitalize the old ring debates of SONET from 10 years ago. These were the UPSR vs BLSR debates. Even though people had their different views, in reality both technologies have/had their uses depending on the traffic pattern, number of nodes, etc.

The Ethernet over SONET vs. RPR just sort of extends that debate to a UPSR vs. BLSR vs. RPR scenario depending on what technology is being supported. The debate is extended to include the type of services parameter supported, e.g., is it a TLS or private line service, is the shared service local to the ring or over a wide area, etc.

Also, if you think about scenarios that the BLSR makes sense in, more than likely an Ethernet over SONET BLSR will be a form of a packet ADM as well.

Finally, on a different point. Why MPLS in the stack??

gea 12/5/2012 | 12:06:37 AM
re: RPR’s New Guise: The Packet ADM "Also, if you think about scenarios that the BLSR makes sense in, more than likely an Ethernet over SONET BLSR will be a form of a packet ADM as well."

Well, I've been out of any loops that intersect with RPR, so what I'm about to say could be hooey. But, the last I heard the RPR standards group were just settling on "re-steering" vs an RPR ring-switch. The RPR ring switch is the packet version of BLSR, but the re-steering doesn't work that way (the endpoints of a flow eventually find the shortest path between them and send the flow that way, as opposed to first sending to the nodes adjacent to the break).

In other words, only the ring switch re-awakens the BLSR arguments. Resteering does not correspond to either UPSR nor BLSR, so it will be a new element in terms of traffic engineering. (Possibly, the ILECs will simply shut off that kind of protection!)
wass 12/5/2012 | 12:06:35 AM
re: RPR’s New Guise: The Packet ADM >But, the last I heard the RPR standards group were just settling on "re-steering" vs an RPR ring-switch.

Actually, the standard allows for both steering and wrapping (unless there were some last minute changes).

Yes, the BLSR is basically a SONET wrapping approach (ring switch). If you wanted to allow for recovery of traffic on the protection links, you would need some sort of resteering approach in the packet ADM portion of the product. This then leads you down further into the debate about RPR as you are adding RPR-like functions to the BLSR Packet ADM. Of course, you could leave BLSR as is and not try to resteer the protection traffic. The disadvantage is that all of the traffic is lost during the failure period. Of course, this may be totally acceptable to some. Another part of the debate....
jAcKyChEn 12/5/2012 | 12:06:16 AM
re: RPR’s New Guise: The Packet ADM Do people really believe that RPR is going to replace SONET? Or is it too little too late?
lightmaster 12/5/2012 | 12:06:14 AM
re: RPR’s New Guise: The Packet ADM "Do people really believe that RPR is going to replace SONET? Or is it too little too late?"

People may believe it, but it won't. RPR is intended to fix the problem that SONET is inefficient for carrying data. Problem is, SONET is GREAT for carrying circuit traffic, which is STILL where all the money comes from. In addition, guess what data service will still dominate the landscape for years to come? Frame relay, delivered mostly over SONET circuits.

RPR has it's place in networks that are data centric if their voice strategy is packet based, for example many cable data networks. However, it will NOT replace SONET in mainstream RBOC applications.
vinay 12/5/2012 | 12:06:08 AM
re: RPR’s New Guise: The Packet ADM This question does not make sense.

RPR can run on "top" of SONET. It provides the packet intelligence and stat mux gains while retaining the CoS guarantees within a SONET/SDH circuit.

Vinay Bannai

jAcKyChEn 12/5/2012 | 12:06:04 AM
re: RPR’s New Guise: The Packet ADM Vinay wrote:

This question does not make sense.

RPR can run on "top" of SONET. It provides the packet intelligence and stat mux gains while retaining the CoS guarantees within a SONET/SDH circuit.

I might be naive here. But in the US, can you show me one carrier who is willing to run RPR on "top" of SONET.

Page 1 / 3   >   >>
Sign In