Resilient Packet Ring Technology
Packet rings have generated plenty of arcane controversy concerning the best ways to handle Ethernet and other packet protocols over the ubiquitous metro fiber-ring topology. But with the new IEEE 802.17 technical standard firmly on the horizon, it’s time for vendors to prove they can make packet rings appeal to the Sonet- and TDM-dominated world of the big incumbents. In short, packet rings are about to grow up.
Resilient Packet Ring (RPR) has been a metro buzzword for a two or three years now, but the noise got pretty deafening towards the end of last year as the Institute of Electrical and Electronics Engineers Inc. (IEEE)’s RPR standardization effort finally hammered competing approaches into a single base for a standard (see Cisco Rounds Up More RPR Support, RPR Divided, RPR: RIP?, RPR: Deadlock Ahead?, and RPR Moves Forward).
The frantic fuss is because RPR promises to be a very smart metro technology, geared to bringing legacy TDM (time-division multiplexing) and newer packet-data services together at high efficiencies onto the metro fiber ring. But there is no chance of the dominant incumbents taking to it in a big way without an agreed-upon standard – and other technologies like next-generation Sonet and switched metro Ethernet are already up and running (see Next-Gen Sonet and Metro Ethernet).
Actually, that technology comparison is a little unfair, as RPR is just a tiny slice of a Layer 2 data-link protocol to provide media access control (MAC) for packets being transported over a ring topology. As developed by the IEEE’s 802.17 RPR Working Group (WG), RPR will run happily over any Layer 1 transport, whether using Sonet/SDH framing or native Ethernet on the transmission links – and with any Layer 3 protocol, for that matter. But RPR still has to attract the attention of vendors and carriers as a potentially key part of a metro solution.
The figure below illustrates the point that RPR will be part of a complete solution and that it can be used with various higher- and lower-level protocols:
(a) Shows RPR running over an existing Sonet/SDH network, which provides the Layer 1 capability (e.g., as an OC12 RPR ring within an OC48 ring). In this example, the carrier uses RPR for its efficiency in supporting Ethernet (and other packet protocols), while continuing to run TDM Sonet/SDH-style services over the remaining Sonet/SDH capacity as normal. This approach might be deployed as a simple RPR blade in the existing Sonet equipment.
(b) Shows RPR running over just the Sonet/SDH PHY (or its 10-Gigabit Ethernet equivalent), which provides the Layer 1 capability. However, RPR now supports both Ethernet and TDM Sonet/SDH-style services. This approach gives RPR a more fundamental role than does (a) and is really a new network architecture.
In the form of earlier proprietary or prestandard versions, RPR has been gaining some ground. “We’ve seen very, very positive traction,” says Jeff Baher, senior marketing manager of the router technology group at Cisco Systems Inc. (Nasdaq: CSCO), referring to that company’s RPR-like Spatial Reuse Protocol (SRP), now an Internet Engineering Task Force (IETF) informational document. “We have just recently introduced OC192 [10 Gbit/s] RPR and are working with a number of customers that are adopting that technology. We also introduced OC48 [2.5 Gbit/s] last year, and we have pretty significant traction now in a number of different types of application – in cable, ISP internetworking, and ILEC and PTT applications.”
Raj Sharma, director of engineering for network architecture at Luminous Networks Inc., another vendor active in RPR, expresses a similar view: “There is a lot of traction in the carriers. We see that Luminous is involved with almost every carrier and cable operator that I can think of in the U.S. and internationally to try out the products, to explain how this technology works, and actually look at the deployment. We have shipped 30,000 ports so far.”
Made for the Metro
The thumbnail justification for this growing interest is that RPR may be a better way of using metro fiber rings in a multiservices environment than either Sonet or Ethernet alone. It promises to combine Sonet’s resilience and availability with the simpler equipment stacks and lower costs of Ethernet to handle multiservice traffic – voice, video, and data – with high efficiency and a range of QOS (quality of service) guarantees. So it would be cheaper on both the capital expenditure (capex) and operating expenditure (opex) sides, and still offer opportunities for enhancing revenues on the service side. Sounds tempting, doesn’t it?
RPR does all this by creating a new packet MAC layer that is optimized for carrier metro ring topologies and conditions. Although RPR is not Ethernet (despite the IEEE’s involvement), everyone is working very hard to ensure that RPR will work efficiently and seamlessly with the existing Ethernet 802 series. So RPR can also appear in enterprise campus networks and in data centers as well as carrier Gigabit and 10-Gigabit Ethernet implementations. Overall, RPR beefs up Ethernet’s rather limited MAC capabilities and allows them to support ring topologies, something Ethernet was not designed to handle.
A basic idea of RPR is to start with a Layer 2 packet technology that supports ring topologies and integrates a packet-switching capability, and to add the necessary QOS definitions within the protocol to bound jitter and delay for time-sensitive traffic like TDM or MPEG streams. The QOS also allows oversubscription of the network for end data services. Thus a base is established from which to start migrating new data services while continuing to offer bread-and-butter legacy TDM and voice services.
By cleverly controlling the way that packets access and traverse a metro ring, RPR can offer some very desirable features:
- Bandwidth multiplication by reusing ring bandwidth for different traffic streams on separate parts of the ring (spatial reuse)
- Statistical multiplexing of traffic within a single large optical ring channel to increase bandwidth-utilization efficiency even further – there is no fixed bandwidth partitioning between services, and traffic aggregation at the ring level gives higher multiplexing gains than at the node level
- A range of QOS guarantees
- Fair sharing of bandwidth among QOS traffic categories
- Sonet-style sub-50ms protection switching for resiliency to ring or node failures
- Simple LAN-like service provisioning
“If you have a collector ring, where naturally all the traffic is running to the hub, then spatial reuse is irrelevant,” says Gady Rosenfeld, director of strategic marketing at Corrigent Systems Inc. “But other factors are the ability to use the protection bandwidth that, in Sonet’s case, is just sitting idle, and – more importantly – the ability to do efficient statistical multiplexing over a shared medium. This kind of statistical multiplexing efficiency can be achieved only when you have a large number of input sources. When you have a medium shared by all of the sources – in RPR’s case, all of the nodes on the ring – you can achieve a much more efficient statistical multiplexing.”
RPR’s characteristics thus fit very well with today’s combinations of committed-information-rate (CIR) and best-effort traffic. Carriers can have a committed rate reserved on the ring, and statistically multiplex the excess rates running on the ring very efficiently – working wonders for their ability to oversell capacity.
Add Sonet-style resilience and management tools, and a provisioning system that is largely decentralized and automatic, and it is easy to see why RPR is attracting attention.